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ABSTRACT 


4 

This  thesis  describes  the  functional  requirements  of 
the  Shipboard  Non-Tactical  Automated  Data  Processing  Program 
(SNAP  II) :  a  microcomputer  system  designed  to  automate 
formerly  manual  procedures  in  the  areas  of  shipboard  supply, 
maintenance,  and  personnel/administration.  A  proposed 
Personnel  Readiness  and  Training  Management  Subsystem  (PTMS) 
is  also  described.  Both  systems  are  analyzed  from  a  user's 
perspective.  Recommendations  are  made  regarding  installation 
approach  and  composition  of  implementation  teams.  Applications 
for  potential  inclusion  in  SNAP  II  are  also  recommended. 
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I.  INTRODUCTION  AND  HISTORICAL  DEVELOPMENT  OF  SNAP 


A.  INTRODUCTION 

The  mid-grade  officer  shortage  in  the  U.S.  Navy  is  well 
known  and  documented.  Results  of  FY  80/81  Officer  Separa¬ 
tion  Questionnaires  indicate  why  attrition  is  high  among 
this  group  of  officers.  The  top  three  reasons  cited  for 
separation  were,  (1)  insufficient  pay,  (2)  too  much  family 
separation,  and  (3)  too  much  crisis  management.  [Ref.  1  ] 

Crisis  management  was  defined  by  resignees  as  excessive, 
unnecessary  paperwork,  inspections,  and  long  hours.  To 
alleviate  this  problem,  steps  have  been  taken  to  cancel, 
consolidate  or  extend  periodicity  of  various  inspections 
and  externally  required  administrative  reports.  Operational 
excellence  has  been  linked  to  inspection  validation  so 
that  an.'.ts  that  demonstrate  superior  performance  are  re¬ 
warded  with  reduced  administrative  requirements. 

One  of  the  most  significant  developments  in  recent 
years  has  been  the  development  of  the  Shipboard  Non- 
Tactical  Automated  Data  Processing  Program  or  SNAP.  This 
ambitious  program  will  culminate  in  the  installation  of 
interactive,  menu  driven  microcomputers  aboard  fleet  units 
for  the  purpose  of  automating  certain  manual  administrative 
functions.  SNAP  is  in  direct  support  of  Chief  of  Naval 


m 


Operations  Objective  5,  "to  reduce  the  administrative  burden 
on  the  fleets".  The  automation  of  administrative  functions 
aboard  ships  should  result  in  increased  efficiency  of  per¬ 
sonnel  utilization  through  time  savings  and  increased 
accuracy  of  report  generation.  SNAP  should  be  an  important 
step  toward  solving  the  administrative  burden  of  crisis 
management.  Beneficial  downstream  effects  of  increased 
personnel  effectiveness,  job  satisfaction,  retention,  and 
readiness  can  be  realized  as  well. 

This  thesis  will  describe  the  historical  development 
of  the  SNAP  concept  in  chapter  I.  Chapter  II  will  detail 
the  integrated  functional  description  of  SNAP  II,  the  micro¬ 
computer  system  to  be  installed  on  small  ships.  Chapter 
III  will  describe  the  functional  capabilities  of  the  Personnel/ 
Administrative/Training  subsystem  proposed  for  SNAP  II 
(PTMS)  and  chapter  IV  contains  a  critical  analysis  of  both 
SNAP  and  PTMS.  Chapter  V  will  propose  suggestions  for 
future  applications  in  the  functional  areas  of  Personnel/ 
Administration/Training  and  recommendations  for  implementa¬ 
tion  of  SNAP  II. 

B.  SNAP  I  -  UYK-5  COMPUTER  REPLACEMENT 

The  AN/UYK-5(V)  computer  system  was  introduced  to  the 
fleet  in  the  mid-1960's  to  support  the  3-M  (Maintenance  and 
Material  Management) ,  SUADPS  (Shipboard  Uniform  Automatic 
Data  Processing  System) ,  and  accounting/financial  functional 
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areas.  The  UYK-5  is  now  installed  in  54  large  ships;  aircraft 
carriers,  combat  stores  ships,  amphibious  assault  ships, 
tenders,  repair  ships,  as  well  as  17  marine  air  groups. 
Additionaly,  12  shore  sites  exist  to  support  operational 
units . 

The  UYK-5  computer  system  suffers  from  a  number 
of  problems  which  have  mitigated  its  effectiveness.  [  Ref. 2: 
p.2]  One  of  the  most  significant  problem  areas  is  the  age  of 
the  system.  This  second  generation  serial  processing 
computer  system  is  now  over  15  years  old  and  is  suffering 
from  decreased  mean  time  between  failures.  Spare  parts  are 
scarce  as  the  system  is  out  of  production.  Another  problem 
associated  with  the  UYK-5  is  saturation.  Many  larger  sites 
operate  on  a  three-shif t-a-day ,  seven-day-week  basis  with 
user  processing  requirements  still  not  met.  A  number  of 
new  programs  have  been  proposed  for  implementation  which 
would  further  overburden  the  system.  These  include  PASS 
(Pay  and  Personnel  Administrative  Support  System) ,  CORS 
(Composite  Operational  Reporting  System) ,  VAMOSC  (Visability 
and  Management  of  Support  Costs) ,  NALCOMIS  (Naval  Aviation 
Logistics  Command  Management  Information  System) ,  and  DEAS 
(Data  Entry  Aboard  Ship) . 

In  1974  OP-91,  now  the  Naval  Data  Automation  Command 
(NAVDAC) ,  initiated  a  study  in  response  to  the  age  and 
saturation  problems  of  the  UYK-5  computer.  [Ref. 3:  p.2] 
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Core  expansion,  replacement  of  tape  drives,  printers  and 
other  peripherals  was  investigated.  A  new  CPU  and  source 
data  automation  equipment  was  recommended.  In  1976  OP-91 
requested  funds  to  replace  the  UYK-5  in  two  phases;  phase  1 
would  replace  the  tape  drives  and  printers,  phase  2  would 
replace  the  CPU  and  other  peripherals.  Naval  Sea  Systems 
Command  (NAVSEA)  developed  the  Plan  and  Milestones  and  the 
Chief  of  Naval  Operations  (CNO)  approved  the  two-phase  re¬ 
placement  that  same  year.  SNAP  I  was  born. 

C.  SNAP  II-ADP  SUPPORT  FOR  SMALLER  SHIPS 

Concurrently,  the  possibility  of  providing  the  same 
type  of  ADP  support  to  smaller  ships  was  being  discussed  in 
the  Navy  community.  In  1970  the  Vice  Chief  of  Naval  Opera¬ 
tions  had  suggested  to  the  CNO  that  small  computers  could  be 
used  aboard  DLG-size  ships  to  improve  general  personnel 
support  and  management.  [Ref.  4] 

A  number  of  feasibility  studies  were  conducted  in  the 
shipboard  environment  as  a  result  of  the  CNO’s  desire  to 
pursue  ADP  applications  in  the  fleet.  Computer  systems 
aboard  USS  FOX,  USS  DAHLGREN,  and  USS  GRIDLEY  delt  primarily 
with  3-M  applications.  USS  BRADLEY  installed  DEAS  and  USS 
MULLINNIX  and  USS  ALBANY  studied  CORS ,  3-M,  and  supply 
functional  aspects. 

The  DAHLGREN  tests  showed  that  even  with  selective 
manning,  ship's  force  personnel  were  unable  to  successfully 


deal  with  emergent  system  operation  and  supporting  software 
problems.  The  crew  was  unable  to  fully  develop  programs 
due  to  time  constraints  but  once  these  applications  were 
designed,  the  shipboard  organization  became  very  dependent 
upon  them.  System  reliability  played  a  direct  role  in  crew 
enthusiasm.  Automated  requisition  status  and  personnel 
files  were  cited  as  extremely  useful  management  devices. 

It  became  apparent  from  the  DAHLGREN  studies  that  the  final 
shipboard  ADP  must  be  reliable,  easy  to  maintain,  and  have 
a  software  package  that  is  centrally  programmed,  debugged 
and  revised. 

The  DEAS  program  was  initiated  by  the  Naval  Supply 
Systems  Command  to  provide  for  more  rapid  transferral  of 
supply  data  between  ships  and  shore  supply  activities.  DEAS 
tests  aboard  MULLINNIX  and  ALBANY  showed  that  DEAS  demon¬ 
strated  a  significant  potential  for  improving  supply  manage¬ 
ment  aboard  ships.  [Ref.  2:  p.5]  For  example,  OPTAR  (Opera¬ 
tional  Target)  budget  maintenance  time  was  reduced  from  two 
hours  per  day  (manual)  to  15  minutes  per  day  (automated) . 

The  CORS  study  indicated  great  potential  for  reducing 
errors  and  speeding  preparation  of  formatted  messages. 

Norv-standard  microcomputers  have  appeared  throughout 


the  fleet  as  commanding  officers  buy  off-the-shelf  systems 
in  an  attempt  to  cope  with  administrative  burdens.  Higher 
echelons  in  the  Navy  cite  higher  aquisition,  software 


development,  and  maintenance  costs  as  reasons  for  the 
development  of  a  standardized,  central  ADP  program  for  the 
fleet. 

In  response  to  the  requirement  for  a  centralized  ADP 
program,  NAVSEA  has  been  designated  to  procure  a  modular 
expandable  system  that  will  meet  the  ADP  requirements  of 
large  and  small  ships  as  well  as  the  supporting  shore 
establishment.  SNAP  I  will  support  large  ships  and  shore 
commands  while  SNAP  II  will  support  the  smaller  ships.  It 
is  anticipated  that  a  Navy-wide  ADP  system  will  result  in 
benefits  in  the  areas  of  standardization  of  hardware  and 
software  and  economies  of  scale  in  procurement,  software 
development,  and  hardware  maintenance. 
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II.  SNAP  II  INTEGRATED  FUNCTIONAL  DESCRIPTION 


A.  INTRODUCTION 

The  purpose  of  SNAP  II  is  to  replace  manual  functions 
with  automated  systems  to  support  the  organizational,  non- 
tactical  requirements  of  small  ships.  The  system  includes 
the  functional  areas  of  maintenance,  supply,  disbursing, 
personnel,  administration,  and  medical.  The  Chief  of  Naval 
Material  (CHNAVMAT)  was  tasked  to  provide  ADP  development 
plans  for  SNAP  II.  NAVSEA,  under  the  direction  of  CHNAVMAT, 
was  directed  to  develop  hardware  and  software  specifications 
to  satisfy  shipboard  management  information  and  non-tactical 
requirements. 

On  30  March,  1981  CHNAVMAT  published  the  final  Inte¬ 
grated  Functional  Description  (IFD)  for  SNAP  II.  This  document 
contains  the  final  description  of  the  functions  to  be  in¬ 
cluded  in  the  initial,  nucleus  SNAP  II  software  release  in 
mid-1982.  The  IFD  also  contains  specifications  for  future 
applications  to  be  included  in  follow-on  software  updates. 

[Ref.  5] 

SNAP  II  hardware  will  be  broken  into  nine  distinct 
subsystems  or  submenus  as  indicated  in  Figure  1.  SNAP  II 
will  be  designed  to  automate  current  manual  systems  with 
the  flexibility  and  expandibility  to  accept  new  applications. 
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FIGURE 


The  anticipated  advantages  of  the  system  are  as  follows: 


(1)  reduction  of  administrative  requirements 

by  eliminating  certain  manual,  online  files; 

(2)  elimination  of  certain  manual  report  genera¬ 
tion  through  automatic  report  preparation 
and; 

(3)  reduction  in  error  rates  and  time  to  review 

and  correct  documents  by  online  data  validation. 


B.  BACKGROUND 

SNAP  is  managed  under  the  auspices  of  OPNAVINST  5230.16 
and  is  under  the  policy  guidence  of  the  Fleet  Non-Tactical 
ADP  Policy  Council.  The  program  itself  consists  of  two 
major  efforts: 

1.  SNAP  I  -  replaces  ship  and  shore  based  UYK-5 
computers  with  third  generation,  standard 
automated  information  hardware  and  software. 

2.  SNAP  II  -  provides  smaller  ships  and  selected 
shore  activities  with  a  standard  ADP  system 
compatible  with  SNAP  I  hardware  and  software. 

The  key  concept  behind  the  SNAP  program  is  that  fleet 
operational  and  support  activities,  both  afloat  and  ashore, 
will  be  provided  with  a  standard,  automated  information 
system.  Functional  requirements  for  all  SNAP  installations 
will  be  identical  even  though  the  hardware  and  software 
packages  may  be  varied.  Different  vendors  will  be  required 
to  meet  the  same  functional  specifications  to  ensure  that 
fully  compatible  and  integrated  support  exists  for  all  SNAP 
systems . 
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All  SNAP  systems  will  be  equipped  with  telecommunica¬ 
tions  capability.  The  nucleus  electronic  transfer  of  infor¬ 
mation  capability  will  consist  of  offship  diagnostic  software 
trouble-shooting  between  SNAP  I  and  SNAP  II  computers. 
Communication  between  SNAP  and  non-SNAP  computers  will  be 
accomplished  via  offline,  machine-readable  media  (tapes, 
cartidges,  disks,  paper  tapes,  cards) . 

C.  OBJECTIVES 

The  primary  goal  of  SNAP  II  is  to  achieve  CNO  objective 
number  5,  "to  reduce  the  administrative  burden  on  the  fleet". 
To  support  this  objective  SNAP  II  will  automate  functions 
in  the  areas  of  maintenance,  supply,  pay,  personnel,  admin¬ 
istration,  and  medical/dental.  The  system  should  be  designed 
to  run  without  operators  in  an  unmanned  space.  SNAP  II 
should  also  be  designed  to  be  utilized  by  functional  area 
specialists  currently  assigned  with  no  increased  manning  re¬ 
quirements  associated  with  indoctrination  and  use  through 
the  employment  of  menu  techniques  and  online  help  functions. 
Offship  formal  training  requirements  should  be  reduced  as  a 
result.  The  use  of  standard  operations  across  fleet  in¬ 
stallations  should  assuage  learning  time  needed  for  inter¬ 
unit  transferees. 
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D.  SPECIFIC  PERFORMANCE  REQUIREMENTS 

System  inputs  will  be  in  two  forms:  (1)  online  user 
input  and  (2)  offship  input  via  magnetic  media.  Input  data 
validation  will  be  conducted  internally  prior  to  utilization. 
Error  messages  should  inform  the  user  of  incorrect  input 
for  his  correction  in  the  case  of  user  entry.  Offship  data 
input  will  be  corrected  by  the  user,  if  possible,  or  returned 
to  the  originator  for  correction. 

A  goal  of  system  response  time  of  three  seconds  or 
less  has  been  established  for  single  file  access  and/or 
data  element  validation  actions.  Response  time  is  defined  as 
the  time  between  executing  the  action  code,  e.g.  pressing 
the  ENTER  key,  and  the  time  of  the  display  of  the  first 
character  of  the  response  on  the  terminal.  Actions  re¬ 
quiring  longer  processing  times,  such  as  multiple  file 
access  or  the  setting  up  of  new  files,  will  display  a 
message  indicating  that  the  requested  action  is  in  progress. 

The  goal  here  is  to  inform  the  user  that  the  system  under¬ 
stands  his  query  and  is  acting  accordingly.  This  objective 
is  key  to  user  acceptance  and  reduced  operator  frustration. 

E.  FUNCTIONAL  AREAS 

1.  Maintenance 

The  maintenance  subsystem  should  provide  automated 
information  to  aid  supervisors  to  effectively  manage  ship's 
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maintenance  requirements.  SNAP  II  will  support  the  Current 
Ship's  Maintenance  Plan  (CSMP)  to  aid  the  commanding  officer 
in  the  management  and  prioritization  of  efforts  to  correct 
material  deficiences.  The  Ship's  Force  Work  List  (SPWL) 
will  be  incorporated  to  permit  enhanced  flexibility  in 
managing  the  expenditure  of  ship's  force  manhours. 

The  system  should  ensure  correct  source  data  trans¬ 
mission  to  outside  activities  thereby  increasing  the  accuracy 
and  effectiveness  of  maintenance  information  for  the  generat¬ 
ing  and  receiving  units.  Administrative  workload  should  be 
assuaged  by  the  replacement  of  manual  logs  and  files  with 
automated  entries.  The  maintenance  subsystem  should  provide 
simple  menu  selection  of  routines  for  repetitive  work  thus 
increasing  maintenance  action  speed  and  quality.  Low  level 
maintenance  men  will  be  able  to  automatically  order  parts 
and  track  their  progress  through  the  supply  system  thereby 
increasing  the  effectiveness  of  the  maintenance/supply 
interface. 

The  SNAP  II  maintenance  subsystem  should  also 
provide  skeleton  formats  for  reports  now  prepared  manually 
such  as  Casualty  Reports  (CASREPTS)  and  Unit  Reports  (UNITREPS) . 
The  system  should  also  assist  in  work  package  maintenance, 
management,  and  automated  transfer  via  magnetic  or  hardcopy 
means.  An  automated  Trouble  Log  should  permit  better 
management  of  emergent  ship's  force  work.  Special 
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scheduling/management  programs  should  be  provided  to  assist 
supervisors  to  better  manage  work  accomplishment  during  the 
complex  overhaul  evolution. 

The  maintenance  subsystem  should  support  the 
Preventive  Maintenance  System  (PMS)  and  will  automatically 
process  the  Quarterly  Force  Revision  (QFR) .  Schedule  prep¬ 
aration  and  assistance  for  PMS  and  the  QFR  will  be  provided 
as  well.  Weekly  schedules  of  required  maintenance  actions 
for  the  upcoming  week  will  be  obtainable  from  the  SNAP  II 
system.  This  scheduling  aid  should  compensate  for  the 
ship’s  schedule,  equipment  status,  and  absence  of  key 
technical  personnel  and  alert  managers  to  potential 
scheduling  problems.  Detailed  assistance  for  maintenance 
men  should  be  provided  through  automated  Tag  Out  Log  and 
Equipment  Guide  List  (EGL)  information  where  needed.  PMS 
schedules  can  be  monitored  throughout  the  maintenance  cycle 
to  provide  managers  with  work  breakdown  analysis  of  work 
loading,  thereby  keeping  supervisors  constantly  aware  of 
potential  manning  constraints.  The  ship's  schedule,  correc¬ 
tive  maintenance  outstanding,  and  preventive  maintenance  due 
will  be  used  in  this  analysis. 

Specific  maintenance  functions  for  the  initial  and 
future  software  releases  of  SNAP  II  and  detailed  functional 
descriptions  may  be  found  in  reference  5,  enclosure  2, 
pages  15-21. 


2.  Supply 

The  supply  subsystem  should  automate  current 
manual  supply  procedures  in  the  areas  of  inventory  control, 
financial  accounting.  Special  Accounting  Class  224,  food 
service,  and  ship's  store.  Labor  intensive  file  maintenance 
and  record  keeping  are  currently  the  practice  in  these 
functional  areas.  SNAP  II  automation  is  intended  to 
eliminate  routine  filing,  eliminate  simple  arithmetic  and 
clerical  errors,  and  automatically  generate  forms  needed 
for  daily  supply  operations.  The  system  will  automatically 
process  incoming  magnetic  and  machine- readable  supply 
information,  thus  mitigating  manhour  consuming  and  error 
prone  data  entry  and  filing. 

The  inventory  control  function  should  be  accomp¬ 
lished  by  online  generation,  editing,  and  procurement  of 
user  requirements.  The  system  will  track  the  supply  re¬ 
quirement  from  the  generation  of  the  request  through  the 
onboard  receipt  of  the  material.  Online  information  regarding 
supply  parts  status  will  be  provided  for  the  monitoring  of 
requirements.  The  supply  subsystem  will  allow  for  the  re¬ 
cording  of  issues,  recording  of  demand,  periodic  reorder 
of  material,  setting  of  reorder  levels,  and  adjustment  of 
inventory  by  receipt  or  inventory.  Online  record  maint¬ 
enance  should  improve  accuracy  and  assuage  the  need  for 
labor  intensive,  error  prone  maintenance  of  paper  files. 
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The  financial  accounting  function  should  include 
the  functional  areas  of  internal  budgeting,  OPTAR  record 
keeping,  and  consumption.  The  internal  budgeting  system 
should  be  flexible  enough  to  allow  the  tailoring  of  budget 
reporting  to  any  desired  level;  different  departments  may 
require  different  types  of  budgeting  with  various  funding 
categories.  OPTAR  accounting  will  provide  for  the  Current 
OPTAR  report,  ten  day  transmittals,  Summary  Filled  Order 
Expenditure  Difference  Listing  (SFOEDL)  ,  and  Age  Unfilled 
Order  Listing  (AUOL) .  These  reports  will  be  generated  and 
received  by  magnetic  tape  and  processed  online  thereby 
reducing  manual  research. 

SNAP  II  should  also  allow  for  the  use  of  standard 
inventory  control  tools  to  support  control  of  Special 
Accounting  Class  224  material  carried  on  replenishment  ships. 
Procurement,  receipt,  and  issue  functions  will  be  supported 
on  oilers  and  ammunition  ships  as  a  result. 

The  clerical  functions  of  the  Mess  Management 
Specialist  rating  should  be  automated  by  the  food  service 
function.  Assistance  in  menu  planning  and  preparation  as 
well  as  inventory  control  and  return  generation  should  be 
provided.  The  inventory  control  function  should  assist  the 
food  servicemen  in  a  number  of  areas.  Inventory  management 
assistance  should  be  provided  in  the  areas  of  manual  and 
automatic  procurement  of  food  supplies.  For  example,  when 


a  preset  low  end  reorder  limit  is  reached,  inventory  will 
be  ordered  for  restock.  Information  on  future  menu  needs 
will  be  used  to  order  predeployment  loadouts  or  to  top  off 
inventories  prior  to  underway  replenishment  (UNREP) .  Other 
areas  of  inventory  support  include  breakout  and  receipt 
assistance,  the  prevention  of  food  spoilage  via  stock 
rotation,  and  the  support  of  food  transfer  to  both  general 
and  private  dining  facilities. 

The  return  generation  subfunction  of  the  food 
service  function  provides  aids  for  inventory,  stock  recon¬ 
ciliation,  and  automatic  provision  of  returns.  The  menu 
planning  and  preparation  subfunction  will  prepare  and  print 
menus.  It  should  also  generate  breakout  forms  taking  into 
account  the  menu  selected  and  the  number  of  servings  to  be 
prepared.  Food  preparation  worksheets  will  also  be  provided 
to  assist  in  menu  preparation. 

The  ship's  store  function  should  improve  the 
accuracy  of  records  and  reduce  the  administrative  burden 
on  ship's  store  personnel  through  the  utilization  of  point- 
of-sale  inventory  control  and  automatic  record  updates. 
Automated  procurement  assistance  will  be  provided  via  on¬ 
line  menu  selection  of  procurement  documents.  For  example, 
the  input  of  stock  quantities  required  can  be  used  to  re¬ 
view,  on  the  terminal,  stock  requiring  reorder  and  procure¬ 
ment.  This  mode  can  be  used,  while  a  salesman  or  vendor  is 
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present,  to  review  status  of  previously  ordered  inventory  or 
to  prepare  procurement  documents  for  stocks  requiring. 


The  ship's  store  function  should  also  assist  in 
inventory  management,  the  prevention  of  accumulated  stock 
items  through  stock  rotation,  and  the  definition  of  inventory 
levels  and  automatic  reorder  relevent  to  the  ship's  future 
operating  schedule.  The  system  can  also  support  a  markup 
system  based  on  the  policies  set  down  by  the  ship's  Commanding 
Officer.  This  markup  scheme  can  be  keyed  to  volume  or 
category  of  sales. 

A  detailed  description  of  specific  supply  functions 
cam  be  found  in  reference  5,  enclosure  2,  pages  21-38. 

3.  Disbursing 

SNAP  II  should  provide  support  to  three  areas  of 
the  personnel  pay  system;  (1)  military  pay,  (2)  travel  pay, 
and  (3)  cash  book  maintenance.  The  online  pay  system  should 
aid  in  the  preparation  of  the  following  services;  automatic 
pay  calculation,  Leave  and  Earnings  Statements  (LES) ,  pay¬ 
ment  documents,  checks,  and  supporting  paperwork  such  as 
allotments.  The  system  should  also  mesh  with  the  cash  book 
to  ensure  proper  posting.  The  SNAP  II  pay  system  should 
generate  travel  claims  given  input  of  the  traveller's 
schedule  and  input  of  other  expenses  selected  from  a  menu 
checklist.  The  system  will  also  make  sure  that  personnel 
filing  claims  for  similar  trips  will  receive  comparable 
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reimbursement.  Cash  book  accounting  will  be  automated  as 
well.  Accurate  posting  of  cash  book  entries  should  be 
accomplished  through  an  interface  between  the  pay  and  travel 
functions.  The  disbursing  function  requires  unique  security 
precautions  and  SNAP  II  should  provide  the  necessary 
security  measures  to  prevent  unauthorized  access  and  use. 

A  list  of  disbursing  functions  may  be  found  in 
reference  5,  enclosure  2,  pages  37-38. 

4 .  Personnel 

Portions  of  the  service  record  suitable  for  auto¬ 
mation  should  be  maintained  by  SNAP  II.  Privacy  Act  safe¬ 
guards  will  be  included  to  ensure  proper  disclosure  of 
personnel  information.  The  system  should  ease  the  transfer 
of  personnel  through  the  use  of  magnetic  tape  cartridges. 
Magnetic  media  will  provide  for  the  automated  input  of 
personnel  data  to  the  receiving  command.  Page  13  entries 
and  portions  of  page  4,  5,  6,  and  7  entries  do  not  lend 
themselves  to  automation  and  will  remain  in  hardcopy  form. 
System  integrity  should  be  maintained  through  automatic 
preparation  of  paper  copies  of  service  record  entries 
prior  to  transfer.  Automated  service  record  entries  will 
support  a  personnel  data  base  for  administrative  and  depart¬ 
mental  reports.  This  data  base  will  be  the  only  site  of 
personnel- related  information.  Due  to  Privacy  Act  constraints, 
only  personnel  with  proper  authority  will  be  allowed  to 
change  or  delete  personnel  data  in  this  file. 
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A  more  detailed  description  may  be  found  in 
reference  5,  enclosure  2,  pages  38-43. 

5 .  Administration 

Three  classes  of  users  will  be  accomodated  by  the 
administrative  subsystem;  (1)  the  Executive  Department,  (2) 
other  departments,  and  (3)  embarked  units.  The  Executive 
Department's  functions  should  encompass  the  entire  crew, 
while  the  individual  departmental  functions  will  be  tailored 
to  the  information  needs  of  each  department  head.  Functional 
areas  common  to  both  management  levels  include  a  general 
inventory  management  aid,  a  training  administration  support 
program,  and  word  processing.  Embarked  unit  support  will 
be  given  in  the  areas  of  clerical,  training  support,  and 
word  processing. 

Executive  Department  functional  aid  can  be  seg¬ 
regated  into  five  categories: 

(1)  basic  clerical  support, 

(2)  personnel  clerical  support, 

(3)  inventory  management, 

(4)  training  administration, 

(5)  word  processing. 

Basic  clerical  support  will  entail  a  tickler  system  to  aid 
in  the  timely  submission  of  externally  required  reports  and 
response  to  correspondence.  Library  control  of  administra¬ 
tive  publications  and  logs  and  records  maintenance  should 
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also  be  accomplished  through,  basic  clerical  support. 

Personnel  clerical  aid  should  be  affected  through  an  inter¬ 
face  with  the  personnel  data  base.  Authorized  users  should 
be  able  to  review  data  for  use  as  inputs  to  a  wide  range  of 
personnel  bills  needed  to  support  the  ship's  operational 
requirements . 

The  initial  training  support  system  will  support 
the  recording  of  ship's  training  requirements  and  onboard 
personnel  qualifications.  Word  processing  should  help  in¬ 
tegrate  the  Executive  Department  functions.  SNAP  II  should 
facilitate  the  transfer  of  information  between  data  processing 
files  and  the  word  processing  system. 

Aid  to  other  departments  should  consist  of  four 
support  areas: 

(1)  basic  clerical, 

(2)  inventory, 

(3)  training  administration, 

(4)  word  processing. 

Basic  clerical  support  should  consist  of  an  online  log  and 
record  keeping  capability  similar  to  the  support  provided 
to  the  Executive  Department,  but  on  a  more  limited  basis. 

The  inventory  system  will  provide  assistance  in  maintaining 
records  of  tools,  general  purpose  electronic  equipment 
(GPETE) ,  and  the  like.  The  training  subsystem  should 
enable  department  heads  to  more  effectively  utilize  scarce 


training  resources  through  the  planning  and  recording  of 
individual  and  ship  training  opportunities.  The  word 
processing  capability  available  to  the  departments  will  be 
similar  to  that  afforded  to  the  Executive  Department  to 
assist  in  general  administration. 

Embarked  units  should  be  provided  services  similar 
to  those  received  by  ship's  departments.  Embarked  staffs 
and  aviation  detachments  will  be  considered  as  just  another 
department  in  the  SNAP  II  scheme. 

A  list  of  administrative  requirements  is  found  in 
reference  5,  enclosure  2,  pages  38-43. 

6 .  Medical 

The  medical  subsystem  should  provide  support  in 
three  basic  functional  areas: 

(1)  personnel  system  interface, 

(2)  inventory  control, 

(3)  diagnostic  support. 

The  personnel  system  interface  will  support  special  programs 
such  as  shot  records  and  the  audiogram  program.  It  will 
also  aid  in  the  scheduling  of  medical  and  dental  appoint¬ 
ments.  The  inventory  control  system  should  permit  accurate 
record  keeping  of  required  medical  materials  and  instru¬ 
ments.  The  diagnostic  aid  capability  should  help  the  duty 
corpsman  diagnose  sickness  through  the  input  of  patient 
symptoms  and  feedback  responses. 


A  more  detailed  description  of  the  functional 
requirements  may  be  found  in  reference  5,  enclosure  2,  pages 
42-43. 


F.  IMPACTS 

The  main  impacts  of  SNAP  II  can  be  described  in  terms 
of  two  categories:  (1)  the  impact  on  the  ship  and,  (2)  the 
impact  between  the  ship/shore  establishment's  operational 
philosophy. 

1.  Equipment  Impacts 

The  main  impact  on  hardware  exists  in  the  ship/ 
shore  interface.  The  present  ship/shore  interface  is 
accomplished  by  manual,  non-automated  means,  e.g.,  hardcopy 
reports,  messages,  microfiche,  etc.  The  ship/shore  inter¬ 
face  must  utilize  the  automated  transfer  of  data/information 
if  the  goal  of  reduced  administrative  burden  is  to  be 
obtained.  This  will  require  a  ship/shore  hardware/software 
interface  to  ensure  a  smooth,  two-way  exchange  of  information 
between  data  bases.  In  other  words,  SNAP  I  and  II  must  be 
functionally  compatible. 

2.  Software  Impacts 

Since  no  current  automated  systems  are  being  re¬ 
placed,  software  impacts  are  considered  to  be  negligible. 

The  ship  impact  should  be  mainly  in  the  area  of  training 
required  to  operate  SNAP  efficiently  and  effectively.  The 
shore  establishment  impact  will  be  considerable,  however, 
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since  dramatic  changes  in  existing  shore  software  will  be 
required  to  ensure  proper  integration  with  automated  fleet 
units.  The  shore  commands  will  also  be  required  to  operate 
manual  and  automated  systems  concurrently  for  the  five  or 
six  year  installation  phase. 

3.  Organizational  Impacts 

Onboard  ships,  the  major  organizational  impact  of 
SNAP  II  will  be  the  shift  from  manual  to  ADP  methods  and 
the  attendant  restructuring  of  work  tasks.  This  realloca¬ 
tion  of  effort  will  result  in  additional  workload  in  some 
areas  and  a  workload  mitigation  in  other  areas.  The  over¬ 
all  effect  of  this  workload  redistribution  should  be  greater 
efficiency  and  thus  more  work  accomplishment.  The  organiza¬ 
tional  training  impact  should  result  in  orienting  training 
requirements  toward  a  broad  category  of  general  user  rather 
than  setting  up  a  training  program  for  each  clerical  user 
in  a  new  organizational  structure.  This  additional  training 
impact  should  be  assuaged,  in  time,  as  Navy  schools  incorporate 
the  SNAP  methodology  into  their  training  requirements. 

The  organizational  impact  on  the  interface  with  the 
shore  establishment  is  an  area  where  functional  sponsors  will 
need  to  take  decisive  action  to  ensure  the  success  of  SNAP. 
Shore  commands  will  need  to  overhaul  their  "paperwork" 
philosophy  of  operations.  Hardcopy  reports,  as  inputs  to 
fleet  data  bases,  must  be  restructured  and  consolidated  to 
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permit  automated  transfer  to  fleet  units.  The  shore 
establishment  must  ensure  that  information  exchanges  between 
shore  commands  and  fleet  units  are  via  automated  means. 

The  receipt  and  processing  of  information  must  be  automatic, 
precluding  the  need  to  manually  enter  data  or  create  paper 
documents  for  offship  transmittal.  Interfaces  must  be 
built  into  the  system  that  require  no  data  processing  ex¬ 
pertise  except  the  ability  to  mount  the  input  tape  or  cart¬ 
ridge  when  called  for.  System  design  must  also  preclude 
the  need  for  storage  of  a  vast  library  of  magnetic  tapes 
or  disks. 
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III.  PROPOSED  PERSONNEL  READINESS  AND  TRAINING  MANAGEMENT 

SUBSYSTEM 


The  previous  chapter  described  the  functional  re¬ 
quirements  for  the  SNAP  II  software  to  be  installed  on 
small  ships  in  the  1980's.  This  chapter  will  describe  a 
shipboard  personnel  readiness  and  training  management 
system  proposed  for  inclusion  in  the  SNAP  II  software 
package . 

A.  BACKGROUND 

Personnel  lacking  the  required  skills  to  operate  and 
maintain  ship's  systems  adversely  impact  upon  material 
readiness  in  the  shipboard  environment.  Currently,  manual 
procedures  are  used  almost  exclusively  to  manage  personnel 
and  training  functions  aboard  ships.  As  a  result,  such 
functions  as  receipt,  assignment,  training,  qualification 
allocation  and  detachment  of  ship's  company  involve 
excessive  manhours  and  a  relatively  high  probably  of 
errors  which  result  in  decreased  efficiency  and  effective¬ 
ness  of  ship's  force  personnel.  [Ref.  6:  p.l  ] 

The  shipboard  personnel  readiness  and  training  management 
subsystem  is  an  effort  to  improve  overall  ship's  material 
readiness  by  improving  the  ship's  maintenance  management. 
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The  Maintenance  System  Development  Program  (MSDP)  is  the 
focus  of  this  effort  and  as  directed  by  the  Naval  Sea 
Systems  Command  (NAVSEA)  under  the  sponsorship  of  the  Deputy 
Chief  of  Naval  Operations  for  Logistics.  MSDP  investigators 
observed,  in  1979,  that  the  "...Navy's  maintenance  infor¬ 
mation  systems,  generally,  have  been  designed  to  serve  the 
functional  needs  of  analysts  and  managers  external  to  the 
ship."  [Ref. 6:  p.2]  These  externally  generated  informa¬ 
tion  requirements  failed  to  recognize  the  information 
needs  of  the  shipboard  manager  nor  did  they  realize  his 
inability  to  produce  the  required  information  accurately 
and  on  time  without  an  inordinate  consumption  of  available 
ship's  manhours.  MSDP  investigators  observed  that  infor¬ 
mation  quality,  and  attendant  decisions  regarding  mainten¬ 
ance  system  management  and  material  readiness,  could  be 
improved  through  the  introduction  of  an  integrated  computer 
system  for  shipboard  maintenance  management  information. 

They  also  realized  that  personnel  are  an  integral  part  of 
the  maintenance  assets  of  all  ships  and  that  a  personnel 
readiness  and  training  management  package  was  required  to 
access  the  full  potential  of  personnel  resources  in  the 
maintenance  function. 

In  1979,  NAVSEA  commissioned  the  Navy  Personnel 
Research  and  Development  Center,  San  Diego  (NPRDC)  to  de¬ 
sign  the  subsystem  specifications  for  a  shipboard  Personnel 
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Readiness  and  Training  Management  Subsystem  (PTMS) .  NPRDC 
reviewed  the  literature  regarding  personnel  data  management 
systems  and  shipboard  non-tactical  automated  data  processing 
systems  and  analyzed  the  manual  procedures  related  to 
personnel  and  training  management.  As  a  result,  NPRDC 
selected  the  procedures  ammenable  to  automation  and  designed 
the  subsystem  specifications  for  a  shipboard  computer- 
assisted  personnel  readiness  and  training  management 
package.  [Ref. 6:  App.  B  ]  NPRDC  recommended  that  the  PTMS 
specifications  be  used  to  develop  a  nucleus  personnel 
readiness  and  training  management  capability  for  the  SNAP 
II  system.  [Ref. 6:  p.6  ]  PTMS  was  developed  by  LCDR  John 

A.  Dollard  at  NPRDC.  This  chapter  will  summarize  the  PTMS 
capabilities  recommended  for  inclusion  in  the  SNAP  II 
software  package. 

B.  PTMS  REQUIREMENTS 

PTMS  was  designed  to  automate  manual  personnel  and 
training  functions  aboard  ships.  The  objectives  of  PTMS 
are  to:  (1)  mitigate  administrative  personnel  and  training 
workload  associated  with  ship's  maintenance  management 
and,  (2)  improve  personnel  readiness  and  training  management 
PTMS  is  intended  to  automate  repetitive  aspects  of  the 
personnel  and  training  functions  including  personnel 
receipt,  assignment  and  transfer,  training  scheduling, 
qualification  monitoring,  and  personnel  forecasting.  PTMS 
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is  intended  to  automate  repetitive  aspects  of  the  personnel 
and  training  functions  including  personnel  receipt, 
assignment  and  transfer,  training  scheduling,  qualification 
monitoring,  and  personnel  forecasting.  PTMS  should  reduce 
the  time  and  work  required  to  access  personnel/ training 
information  and  provide  better  control  in  this  area.  PTMS 
should  also  reduce  database  errors  through  interactive 
source  data  entry,  eliminate  repetitive  data  inputs,  and 
generate  automatic  personnel/ training  reports,  thereby 
improving  the  accuracy,  consistency,  and  timeliness  of 
these  reports.  PTMS  should  also  inform  managers  of  personnel 
skills  and  deficiencies,  schedule  and  review  future  training 
requirements,  and  forecast  availability  of  personnel  qualified 
to  perform  maintenance  tasks. 

PTMS  can  be  used  directly  by  functional  users  such  as 
division  officers,  training  petty  officers,  personnelmen, 
duty  section  petty  officers,  etc.  Access  can  be  gained  via 
online  terminal  and  printers  located  in  various  offices  and 
workcenters  around  the  ship.  PTMS  should  generate  selected 
reports  for  internal  and  external  information  requirements. 
Offship  data  and  reports  will  be  transmitted  in  machine- 
readable  form  to  facilitate  integration  with  the  shore- 
based  SNAP  I  systems. 

It  is  intended  that  PTMS  will  support  the  record 
keeping  and  reporting  requirements  with  regard  to  shipboard 
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personnel  readiness  and  training  management  functions. 

These  functions  include: 

(1)  assistance  in  the  performance  of  preventive 
and  corrective  maintenance  tasks  through  the 
identification  of  personnel  qualification  re¬ 
quirements  ; 

(2)  inventory  maintenance  of  personnel  qualifica¬ 
tions  and  skills; 

(3)  provision  of  scheduling  aids  to  ensure  the 
future  availability  of  required  skills. 

PTMS  will  be  segregated  into  two  modules;  (1)  personnel 
readiness  and,  (2)  training  management.  Seven  primary 
functional  areas  are  included  in  the  PTMS  specifications: 

(1)  ship's  personnel  office  administration, 

(2)  shipboard  personnel  assignment, 

(3)  personnel  qualification  record  keeping, 

(4)  leave  administration, 

(5)  billet  and  skill  inventory  management, 

(6)  training  requirements  maintenance, 

(7)  required  school  management. 

These  functions  are  shown  in  Figure  2.  [Ref. 6:  pp.5-7  ] 

The  ship's  personnel  office  administration  function 
includes  medical  and  service  record  information  storage 
and  retrieval,  projected  personnel  gains/losses  reporting, 
optical  character  reader  (OCR)  generation  of  temporary 
additional  duty  (TAD)  orders  and  leave  papers,  and  the 
preparation  of  check-in  and  check-out  sheets  for  personnel 
arriving  to  and  departing  from  the  ship.  The  shipboard 
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FIGURE 


r- 


personnel-  assignment  function  includes  assignment  data 
storage  and  retrieval,  the  preparation  of  personnel  assign¬ 
ment  rosters  and  recall  bills,  and  personnel  availability 
forecasts.  The  personnel  qualification  record  keeping 
function  includes  personnel  qualification  data  storage, 
retrieval  and  summaries  for  division  officer  notebook  pre¬ 
paration.  Work  center  PQS  progress  reporting  and  re¬ 
qualification  requirements  reporting  is  also  included. 

The  leave  administration  function  includes  data  entry  and 
retrieval  for  leave  requests  and  approval,  leave  status 
monitoring,  and  leave  papers  preparation.  The  billet  and 
skill  inventory  management  function  includes  billet/skill 
data  storage  and  retrieval,  billet  assignments,  billet/ 
skill  requirements  monitoring,  and  Watch  Quarter  and  Station 
Bill  (WQ&SB)  generation.  The  training  requirements  main¬ 
tenance  function  includes  training  event  data  storage, 
retrieval,  scheduling,  and  progress  reporting,  ttaining 
requirements  summary  preparation,  and  training  event 
history  and  deficiency  reporting.  The  required  school 
management  function  includes  school  data  storage,  retrie¬ 
val,  course  catalog  review,  required  school  graduate  re¬ 
porting,  course  quota  control,  student  assignment  and 
scheduling,  and  orders  preparation  for  schools. 
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C.  PTMS  GENERAL  CHARACTERISTICS 

PTMS  is  intended  to  be  an  online  data  base  system 
which  includes  a  file  management  capability.  In  other 
words,  a  central  data  base  will  house  various  categories 
of  related  information  for  access  via  remote  terminals. 
Since  this  one  data  base  will  be  used  for  decision  making 
by  many  managers,  accuracy  and  validity  of  data  will  be 
important  considerations  for  PTMS  operation  and  mainte¬ 
nance.  To  this  end  it  is  essential  that  PTMS  have  the 
capability  of  cross-checking  displayed  data  during  re¬ 
view  as  well  as  reviewing  information  prior  to  making 
permanent  changes  to  the  data  base/files. 

Timing  constraints  require  that  data  processing  be 
accomplished  within  the  framework  of  a  single  working 
day.  Significant  time  savings  and  reduced  personnel 
workload  are  a  goal  of  PTMS  as  well.  Another  objective 
of  PTMS  is  to  gain  user  confidence  in  system  reliability 
by  establishing  a  response  time  of  three  seconds  or  less. 
That  is,  within  three  seconds  of  final  user  input  the 
system  will  display  the  response  or,  in  the  case  of  more 
complex  data  base/file  manipulation,  the  terminal  will 
display  a  message  to  tell  the  user  that  his  request  is  in 
progress. 
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It  is  also  intended  that  the  PTMS  software  be  flexible 
enough  to  permit  program  changes  and  the  addition  of  new 
progress.  Managers  should  have  the  capability  to  make 
changes  to  programs  via  terminal  input.  This  capability 
should  allow  PTMS  to  evolve  as  user  requirements  change 
over  time.  The  file  management  capability  should  give 
the  user  the  ability  to  set  up  his  own  files  for  appli¬ 
cations  unique  to  his  own  needs.  This  ability  for  each 
ship  to  set  up  its  own  unique  files,  separate  from  the 
standard  PTMS  files,  is  an  important  part  of  the  overall 
flexibility  afforded  by  the  proposed  PTMS  package. 

PTMS  is  not  intended  to  be  used  for  the  storage  of 
classified  material.  Therefore  the  problems  associated 
with  the  proper  disclosure  of  classified  material  have 
been  avoided.  However  sensitive  personnel  data  files 
protected  by  the  Privacy  Act  require  that  positive  con¬ 
trols  be  included  in  the  PTMS  design  to  preclude  unauth¬ 
orized  disclosure  of  private  information.  The  design  of 
PTMS  will  include  two  levels  of  protection  to  prevent 
the  unauthorized  disclosure  of  sensitive  information. 

Each  user  will  be  assigned  a  unique  identification  num¬ 
ber  to  be  typed  on  the  terminal  followed  by  the  entry  of 
a  password.  Neither  of  these  entry  codes  will  be  printed 
on  the  terminal  when  entered  to  guard  against  unauthorized 
disclosure. 
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After  entering  the  correct  identification  number  and 
passwork,  a  main  listing,  or  menu,  of  PTMS  programs  will 
be  available  to  the  user.  This  listing  is  intend  to  be 
keyed  to  the  user  identification  number  and  only  those 
programs  authorized  for  access  by  that  particular  user 
will  be  available.  In  this  way  access  to  sensitive  in¬ 
formation  can  be  tailored  to  individuals  on  a  need  to  know 
basis . 

It  is  anticipated  that  each  user  will  be  assigned 
read  and/or  write  privilages  as  well.  Operators  assigned 
"read  only"  access  will  be  able  to  review  information  but 
will  not  be  allowed  to  change  or  enter  data.  This  restrict¬ 
ed  access  should  help  prevent  unauthorized  or  inadvertent 
errors  in  the  data  base/files. 

After  the  user  has  properly  logged  in,  he  may  select 
the  desired  program  from  the  menu.  The  selected  program 
is  then  loaded  into  memory  and  execution  begins.  At 
various  times  during  the  program  execution  the  computer 
will  query  the  user  for  entry  of  data  for  processing.  After 
user  entry  of  the  required  data,  the  system  should  verify 
that  the  data  meets  various  formatting  and  edit  checks. 

If  the  data  does  not  meet  these  validity  checks  the  terminal 
should  display  a  message  indicating  what  the  problem 
entails.  If  a  simple  typing  error  has  been  made,  the  user 
can  retype  the  data  and  continue.  However,  the  user  can 
also  request  a  help  message  if  he  desires  further  information 


regarding  the  data  entry  error.  This  message  should  pro¬ 
vide  information  related  to  the  proper  format  and  context 
of  the  data  in  question.  The  user  can  also  abort  or  restart 
a  program  as  desired.  A  transaction  log  file  records 
user  inputs  to  allow  file  reconstruction  in  case  of  a 
power  outage  or  other  system  failure.  If  a  function  re¬ 
quires  access  to  numerous  programs,  PTMS  will  load  the  re¬ 
quired  programs  for  automatic  execution.  When  the  user 
is  finished  with  the  program,  he  can  either  repeat  the 
same  function  or  return  to  the  menu  for  selection  of  another 
programs . 

D.  PTMS  DATA  BASE  FILES 

The  data  base  is  the  site  of  all  information  for  PTMS. 
This  data  base  is  organized  into  separate  files  of  related 
information  for  ease  of  access.  A  description  of  each  of 
these  files  follows. 

1.  Personnel  Record  File  (PRF) 

The  personnel  record  file  is  designed  to  organize 
information  concerning  individual  crewmembers  such  as 
general  service  data,  dependent  and  next-of-kin  data, 
career/education/training  data,  and  qualification  data. 

The  PRF  is  also  designed  to  organize  shipboard  assignment 
data,  leave  administration  data,  and  medical  record  data. 
Each  personnel  record  can  be  accessed  in  a  number  of  ways; 
social  security  number,  last  or  first  name,  Navy  Enlisted 
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Classification  Code  (NEC) ,  division,  work  center,  prospective 
rotation  date  (PRD),  or  a  combination  of  any  of  these  keys. 
This  permits  easy,  rapid,  and  flexible  entry  to  service 
record  information. 

2.  Billet/Skill  Inventory  File  (BSF) 

The  billet/skill  inventory  file  is  designed  to  contain 
information  concerning  each  billet's  identification  data, 
watchstation  and  skill/qualification  requirements,  and 
personnel  assignment  data.  The  file  can  be  entered  via 
billet  sequence  number  or  by  social  security  number  if  the 
billet  is  occupied. 

3 .  Training  Requirements  Pile(TRF) 

The  TRF  contains  data  related  to  the  requirement  for  and 
status  of  each  training  event  as  well  as  scheduling  data  and 
a  training  event  description.  This  file  is  intended  to  be 
entered  by  a  preassigned  training  event  identification 
number. 

4 .  School  Requirements  File  (SRF) 

This  file  is  anticipated  to  contain  a  listing  for  each 
required  school.  It  should  list  onboard  graduates, 
available  course  quotas,  and  class  convening  dates.  This 
file  will  be  designed  to  schedule  and  monitor  the  progress 
of  up  to  fifteen  students.  User  access  will  be  via  course 
identification  number. 
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5 .  Visitor  Log  Files  (VLF) 


The  vlf  should  contain  information  concerning  clearance 
and  visits  for  potential  and  scheduled  visitors  to  the  ship. 
This  file  may  be  accessed  by  entering  the  visitor's  social 
security  number  or  his  name.  Information  provided  in  this 
file  includes  visitor's  organization,  title  and  clearance, 
anticipated  visit  dates,  and  remarks. 

6 .  Master  Locator  File  (MLF) 

The  MLF  is  designed  to  locate  ship's  personnel  information 
given  a  limited  amount  of  known  information  about  the  crew¬ 
member.  This  file  can  be  entered  via  the  social  security 
number,  first  or  last  name,  NEC,  division,  work  center,  or 
PRD.  In  essence,  the  MLF  provides  access  to  the  Personnel 
Record  File  to  provide  information  such  as  home  address  and 
phone  number  and  is  likely  to  be  used  for  emergency  recalls. 

7 .  Long  Title  File  (LTF) 

The  LTF  is  the  dictionary  of  PTMS  terms.  It  is  designed 
to  contain  codes  and  short  and  long  titles  of  the  modules, 
records,  files,  reports,  and  functions  of  PTMS. 

8 .  Transaction  File  (TXF) 

The  transaction  file  is  intended  to  maintain  an  interim 
record  of  all  entries  and  changes  to  the  PTMS  data  files. 

It  can  be  entered  by  keying  in  time,  the  sequence  number  of 
the  transaction  or  the  Julian  date.  It  is  anticipated  that 
this  file  will  be  periodically  transferred  to  a  magnetic 
tape  history  file  for  future  reference. 
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E.  PTMS  PROGRAM  DESCRIPTIONS 

The  PTMS  data  base/files  previously  discussed  are  used 
for  grouping  information  only.  Information  in  each  file  is 
maintained  on  a  disk  for  retrieval  and  transfer  to  memory 
as  required  by  the  various  programs.  These  programs  are 
the  vehicle  whereby  the  user  can  manipulate  needed  personnel 
and  training  information. 

As  previously  shown  in  Figure  2,  PTMS  is  divided  into 
two  modules;  personnel  and  training  management.  These  two 
modules  contain  various  functions  or  groupings  of  like 
programs.  These  programs  are  grouped  together  because  of 
common  data  requirements,  operational  efficiency,  and  con¬ 
venience.  The  personnel  module  contains  four  program  group¬ 
ings  : 

(1)  personnel  receipt  and  transfer, 

(2)  personnel  assignment, 

(3)  personnel  leave. 

The  training  management  module  has  three  program  groupings : 

(1)  billet  and  skill  inventory, 

(2)  training  requirements, 

(3)  required  schools. 

A  description  of  these  groupings  and  their  programs  follows. 

1.  Personnel  Receipt  and  Transfer 

The  purpose  of  the  personnel  receipt  and  transfer 
grouping  (function)  is  to  permit  users  to  create,  delete, 
review,  and  update  personnel  information.  This  function 
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is  intended  to  assist  users  in  crewmember  check-in  and  check¬ 
out,  career  counceling,  advancement  preparation,  performance 
evaluation,  leave/school  orders  preparation,  and  preventive 
medicine.  There  are  eight  programs  contained  in  the 
personnel  receipt  and  transfer  grouping; 

(1)  personnel  record  creation, 

(2)  personnel  record  update, 

(3)  personnel  record  deletion, 

(4)  personnel  record  review, 

(5)  personnel  record  survey, 

(6)  personnel  check-in/check-out 

(7)  optical  character  reader  (OCR)  document  prepara¬ 
tion, 

(8)  projected  personnel  gain/loss  reporting. 

The  personnel  record  creation  program  should  allow  the 
user  to  add  personnel  records  to  the  personnel  record  file 
(PRF) .  The  program  should  ask  the  user  for  the  social 
security  number  (SSN)  of  the  crewmember  whose  personnel 
record  is  to  be  entered.  If  that  SSN  is  not  already  on 
file,  a  record  is  created  and  the  user  is  asked  to  enter  the 
appropriate  personnel  record  information.  This  information 
includes  such  items  as  name,  rate,  birth  date,  division, 
duty  section,  and  security  clearance.  If  the  SSN  initially 
entered  is  already  on  file,  the  program  should  inform  the 
user  to  use  the  update  program.  If  this  happens  the  user 
can  press  the  ESCAPE  key  (ESC)  to  return  to  the  menu  to 


select  the  update  program.  When  the  user  has  finished 
entering  the  data  for  a  new  personnel  record  he  can  press  the 
ESCAPE  key  whereupon  he  will  be  asked  if  he  wishes  to 
create  another  personnel  record.  A  default  answer  of  "Y" 

(for  yes)  will  appear  on  the  terminal  and  if  the  user 
presses  the  RETURN  key  he  will  be  asked  to  enter  the  SSN 
of  the  next  record.  Typing  an  ”N"  (for  no)  will  indicate 
to  the  program  that  the  user  is  finished  with  the  create 
program  and  the  system  will  return  to  the  program  menu  for 
selection  of  another  program  as  desired.  Access  in  and  out 
of  all  the  PTMS  programs  is  handled  in  much  the  same  way. 

The  personnel  record  update  program  should  allow  the 
user  to  accomplish  simple  or  multiple  updates  of  personnel 
records.  There  are  four  update  options  available: 

(1)  Single  record,  single  item, 

(2)  Single  record,  multiple  items, 

(3)  Multiple  record,  multiple  items, 

(4)  Full  activity,  multiple  items. 

The  user  selects  the  option  and  enters  the  SSN  of  the 
crewmember  to  be  updated  (activity  unit  identification  code 
in  the  case  of  option  4) .  He  also  enters  the  data  item 
number(s)  to  be  updated  (e.g.,  (54)  local  street  address) 
which  are  listed  on  the  terminal  for  selection.  The  user 
can  leave  the  particular  data  item  unchanged  or  he  can 
change  or  delete  the  items  as  required.  When  an  update  is 
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completed,  the  user  has  the  option  of  updating  another 
crewmamber ' s  record,  switching  to  another  update  option,  or 
returning  to  the  menu  for  another  program. 

The  personnel  record  deletion  program  should  permit 
users  to  delete  personnel  records  from  the  personnel  record 
file  (PRF) .  Upon  entry  of  the  crewmember's  SSN,  the  pro¬ 
gram  will  display  the  name  of  the  person  selected  and  will 
query  the  user  whether  he  wants  to  delete  the  record.  A 
default  "Y"  will  appear  whereupon  the  record  can  be  deleted 
Typing  an  "N"  will  abort  deletion. 

The  personnel  record  review  program  should  allow  the 
user  to  review  personnel  records.  The  user  can  review  an 
individual  record,  the  records  of  a  specific  work  center  or 
NEC,  or  the  whole  unit's  records.  Within  these  categories 
the  user  can  select  specific  data  groups  for  review  as 
follows : 

(1)  Entire  record, 

(2)  General  service  data, 

(3)  Assignment  data, 

(4)  Career/education/advancement  data, 

(5)  Dependent/next-of-kin  data, 

(6)  Leave  administration  data, 

(7)  Medical  record  data, 

(8)  Qualification  data. 
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The  personnel  record  survey  program  serves  a  review 
function  similar  to  that  of  the  personnel  record  review 
program  with  the  exception  that  only  terminal  output  is 
available  and  the  data  items  available  for  display  are 
tailored  for  specific  users  (e.g.,  career  councelors, 
yeomen,  corpsmen,  etc.).  Terminal  screen  formats  are 
arranged  to  include  only  those  data  items  needed  by  the 
specific  user.  Six  formats  are  included  in  this  program; 

(1)  receipt  and  transfer,  (2)  career,  (3)  advancement,  (4) 
evaluation,  (5)  religious  and  dependent,  and  (6)  medical. 

The  personnel  check-in/check-out  program  outputs  a 
paper  copy  of  a  crewmember  check-in  or  check-out  sheet. 

The  check-in  sheet  should  include  a  personnel  data  verifica¬ 
tion  section  and  a  Privacy  Act  statement. 

The  optical  character  reader  (OCR)  document  prepara¬ 
tion  program  is  intended  to  permit  users  to  create,  review, 
update,  delete,  and  print  OCR  documents  for  submission  to 
off ship  commands.  Various  pay  and  personnel  reports  are 
included  in  this  category. 

The  projected  personnel  gain/loss  reporting  program 
can  provide  a  terminal  or  hardcopy  output  of  crewmembers 
who  are  expected  to  arrive  to  or  depart  from  the  ship  within 
the  next  90  days.  Listings  can  be  selected  by  rate  or  NEC. 
Information  to  be  displayed  includes  crewmember’s  rate, 
division,  reporting  date  (if  a  gain) ,  loss  date  (if  a  loss) , 
and  PRO. 
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2 .  Personnel  Assignment 

The  second  group  of  programs  in  the  Personnel  Module 
pertain  to  personnel  assignment;  creating,  updating,  re¬ 
viewing,  and  deleting  personnel  assignment  data.  This 
grouping  of  programs  should  help  managers  to  properly  assign 
personnel  to  work  centers,  locate  personnel  on  and  off  the 
ship,  and  assist  in  watch  bill  preparation.  There  are  eight 
programs  grouped  into  the  personnel  assignment  category; 


(1) 

personnel  assignment 

update , 

(2) 

personnel  assignment 

survey, 

(3) 

personnel  assignment 

roster, 

(4) 

personnel  recall. 

(5) 

muster  report. 

(6) 

division  officers'  notebook. 

(7) 

manpower  availability 

status  report, 

(8) 

manpower  availability 

forecast  report. 

A  short  description  of  the  capabilities  of  each  of  these 
personnel  assignment  programs  follows. 

The  personnel  assignment  update  program  should  permit 
the  user  to  review,  update,  and  add  personnel  assignment  data 
items  of  an  individual.  These  items  include  billet  sequence 
number,  division,  work  center,  duty  section,  watch  qualifica¬ 
tions,  bunk  number,  local  address,  etc. 

The  personnel  assignment  survey  program  is  similar  to 
the  personnel  assignment  update  program  with  two  exceptions. 
Information  cannot  be  changed,  only  reviewed.  Also  the 
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information  is  grouped  into  four  categories  or  screen 
formats  that  can  be  selected  from  the  menu;  (1)  billet, 

(2) inport  duty,  (3)  recall,  and  (4)  locator.  Records  can 
be  selected  by  SSN,  NEC,  duty  section,  or  PRD. 

The  personnel  assignment  roster  program  can  output  a 
printed  copy  of  personnel  assignment  data  by  division  and 
work  center. 

The  personnel  recall  program  produces  a  hardcopy 
summary  of  personnel  recall  data,  also  by  division  and  work 
center. 

The  muster  report  program  is  intended  to  produce  paper 
copies  of  muster  report  worksheets  for  each  division  aboard 
ship. 

The  division  officer  notebook  program  produces  a  terminal 
or  paper  output  of  Division  Officer  Notebook  data  items  for 
the  entire  ship  or  for  selected  divisions.  Items  include 
schools  attended,  past  evaluations,  time  in  rate,  PRD,  and 
a  host  of  other  information  useful  to  the  immediate  super¬ 
visor. 

The  manpower  availability  status  report  program  can 
prepare  a  hardcopy  of  terminal  listing  of  personnel,  by  work 
center,  who  are  available  for  tasking  to  jobs.  Rate,  duty 
section,  qualifications,  security  clearance,  and  PRD  are 
among  the  items  included  in  this  report. 
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The  manpower  availability  forecast  report  program 
produces  a  terminal  or  paper  listing  of  crewmember  avail¬ 
ability  to  perform  a  specific  task  broken  down  by  qualifica¬ 
tions  and  time  period  of  the  desired  task.  The  user  enters 
the  required  skill  or  task  and  the  time  period  involved.  The 
program  outputs  a  list  of  personnel  eligible  and  available 
for  the  task  during  the  specified  time  period. 

3 .  Personnel  Qualification  Administration 

The  third  group  of  programs  in  the  Personnel  Module 
relate  to  personnel  qualification.  It  is  intended  that  this 
category  will  enable  users  to  create,  review,  update,  and 
delete  information  related  to  personnel  training  history, 
qualifications,  and  skills.  There  are  three  programs  in¬ 
cluded  in  this  category: 

(1)  personnel  qualification  update  and  review, 

(2)  personnel  qualification  summary, 

(3)  personnel  qualification/requalification  report. 

The  personnel  qualification  update/review  program 

should  allow  users  to  add,  update,  and  review  a  crewmember's 
qualifications  and  training  history  as  well  as  monitor  pro¬ 
gress  toward  PQS  qualification.  Representative  data  items 
included  in  this  program  are  qualification/  requalification 
due  dates,  planned  and  actual  PQS  start  and  completion 
dates,  and  PQS  points  earned. 

The  personnel  qualification  summary  program  is  intended 
to  provide  a  terminal  or  paper  listing  of  individual 
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qualifications  according  to  selected  groups  or  categories 
(e.g.,  ship,  department,  division,  work  center,  duty  section, 
or  individual) .  After  the  user  selects  the  desired  category, 
the  program  should  output  information  concerning  rate, 
division,  work  center,  qualification  type,  title  and  date, 
and  requalification  date. 

The  personnel  qualification/requalification  report 
program  produces  a  hardcopy  or  terminal  report  which  lists 
personnel  who  require  requalification  in  a  particular  skill 
during  the  next  three  months.  It  is  intended  to  contain 
information  such  as  name,  rate,  division,  qualification, 
and  requalification  due  date. 

4 •  Personnel  Leave  Administration 

The  fourth  and  last  grouping  of  programs  in  the  Personnel 
Module  concerns  personnel  leave  administration.  This  function 
is  designed  to  create,  review,  update,  and  delete  personnel 
data  related  to  leave.  Three  specific  programs  are  grouped 
under  this  heading: 

(1)  personnel  leave  data  maintenance  and  review, 

(2)  personnel  leave  status  reporting, 

(3)  personnel  leave  paper  preparation. 

The  personnel  leave  data  maintenance  and  review  program 
should  help  users  to  review,  update,  and  add  information 
related  to  an  individual's  current  or  future  leave.  Leave 
data  manipulated  by  this  program  includes  leave  start/stop 
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dates,  days  requested,  type  leave  granted  (e.g.,  regular, 
emergency,  etc.),  and  leave  address. 

The  personnel  leave  status  reporting  program  is  in¬ 
tended  to  permit  the  user  to  obtain  a  hardcopy  or  terminal 
output  of  information  related  to  personnel  currently  on  leave 
or  those  projected  to  go  on  leave.  The  user  will  have  the 
option  of  breaking  down  his  request  by  various  categories 
(e.g.,  ship,  department,  division,  work  center,  or  duty 
section) . 

The  personnel  leave  paper  preparation  program  should 
aid  the  user  to  prepare  leave  papers.  This  program  should 
generate  leave  papers  for  individuals  or  selected  groups  of 
individuals  who  have  been  granted  leave . 

5 .  Billet  and  Skill  Inventory  Management 

As  previously  discussed,  the  Training  Management  Module 
of  PTMS  contains  three  program  groupings.  The  first 
category  deals  with  billet  and  skill  inventory  management. 

It  is  hoped  that  this  function  will  aid  the- user  to  create, 
review,  update,  and  delete  information  related  to  billet  re¬ 
quirements  and  assignment  as  well  as  billet  skill  proficiencies 
and  shortfalls.  The  billet  and  skill  inventory  management 
function  contains  five  programs: 

(1)  billet  and  skill  inventory  file  maintenance, 

(2)  billet  personnel  assignment  report, 

(3)  billet  skill  requirements  and  skill  deficiency 
report, 
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(4)  personnel  onboard  versus  allowance  report, 

(5)  Watch  Quarter  and  Station  Bill. 

The  billet  skill  inventory  file  maintenance  program 
should  assist  users  to  create,  review,  update,  and  delete 
records  contained  in  the  billet/skill  inventory  file  (BSF) . 
Data  items  for  review/updating  are  grouped  into  four 
categories ; 

(1)  billet/watchstation  requirements  (e.g.,  billet 
sequency  number,  rate,  NEC,  watchstation,  etc.) 

(2)  billet  personnel  assignment  (e.g.,  SSN,  rate, 
division,  PRD,  etc.) 

(3)  billet  skills  (e.g.,  billet  skill  identification 
code) 

(4)  requirements/proficiency  (e.g.,  billet  skill 
title,  skill  proficiency) 

The  billet  personnel  assignment  report  program  can 
generate  a  hardcopy  report  listing  billets  required  to  be 
filled  along  with  the  names  of  those  jobs  already  filled  by 
ship's  personnel.  This  report  is  organized  by  division  and 
billet  sequency  number. 

The  billet  skill  requirements  and  skill  deficiency 
report  program  lists  the  skills  required  by  the  person 
holding  a  particular  billet  aboard  ship.  It  should  also  list 
the  skills  which  are  or  are  not  held  by  the  person  occupying 
that  job.  The  user  will  be  able  to  choose  billets  by  ship, 
department,  division,  work  center,  NEC,  or  PRD. 

The  personnel  onboard  versus  allowance  report  program 
should  help  the  user  compare  a  list  of  personnel  currently 
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assigned  with  a  list  of  billets  authorized  for  the  ship. 

This  program  should  generate  a  hardcopy  or  terminal  output 
to  help  identify  manning  and  skill  area  shortfalls/overages. 

The  Watch  Quarter  and  Station  Bill  program  is  intended  to 
prepare  a  hardcopy  listing  of  Watch  Quarter  and  Station  Bill 
assignments  by  division.  This  paper  output  should  be  con¬ 
venient  for  posting  in  appropriate  work  spaces  and  living 
quarters. 

6.  Training  Requirements  Management 

The  second  program  grouping  in  the  Training  Management 
Module  concerns  training  requirements  management.  It  is 
hoped  that  this  function  will  allow  users  to  create,  review, 
update,  and  delete  date  related  to  training  requirements. 
Outputs  from  this  program  grouping  include  training  event 
description,  scheduling,  progress  tracking,  history,  and 
deficiency  reporting.  Training  requirements  reporting  is 
also  included  under  this  heading.  Three  specific  programs 
are  included  in  the  training  requirements  management  package: 

(1)  training  requirements  file  maintenance, 

(2)  training  requirements  summary, 

(3)  training  event  history  and  deficiency  reporting. 

The  training  requirements  file  maintenance  program  should 

allow  the  user  to  review,  update,  create,  and  delete  records 
in  the  Training  Requirements  File  (TRF) .  The  user  will  be 
able  to  select  one  or  both  of  the  following  data  groups  for 
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data  manipulation;  event  identification  and  description  and/ 
or  event  scheduling  and  progress.  Representative  data 
items  included  in  the  event  identification  and  descrip¬ 
tion  category  are  event  long  and  short  title,  periodicity, 
priority,  mission  area,  action  officer,  evaluation  method, 
outside  services  required,  and  event  description.  The  event 
scheduling  and  progress  category  includes  such  items  as 
event  status  (e.g.,  accomplished,  ongoing,  or  planned), 
start/stop  dates,  and  evaluation  score. 

The  training  requirements  summary  should  generate  a 
terminal  or  hardcopy  summary  of  all  ship's  required  training 
events  by  various  categories.  These  categories  include 
ship,  department,  division,  work  center,  duty  section,  or 
action  officer  responsible  for  the  event. 

The  training  event  history  and  deficiency  reporting 
program  is  intended  to  produce  a  terminal  or  paper  listing 
of  past  and  future  training  events.  It  will  also  note  over¬ 
due  events  along  with  the  number  of  days  that  they  are 
delinquent.  Training  events  can  be  selected  by  ship,  de¬ 
partment,  division,  work  center,  duty  section,  and  indi¬ 
vidual  . 

7 .  Required  School  Management 

The  last  group  of  programs  in  the  Training  Management 
Module  pertain  to  required  school  management.  It  is  hoped 
that  this  function  will  assist  the  manager  to  create. 
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review,  update,  and  delete  information  related  to  ship's 
required  schools .  Reports  related  to  training  course 
description  and  quota  control,  student  scheduling  and  orders 
preparation,  and  graduate  status  and  shortfalls  are  included 
in  this  package.  There  are  six  programs  contained  in  this 
grouping: 

(1)  school  requirements  file  maintenance, 

(2)  school  catalog  summary, 

(3)  required  school  graduate  status  reporting, 

(4)  school  quota  control, 

(5)  student  assignment  and  scheduling, 

(6)  school  orders  preparation. 

The  school  requirements  file  maintenance  program  should 
permit  the  user  to  review,  update,  create,  and  delete  re¬ 
cords  in  the  School  Requirements  File  (SRF) .  The  user  can 
select  one  or  more  of  the  following  data  categories  for  file 
manipulation;  course  identification,  graduate  status,  quota 
control  and/or  student/graduate  schedule/inventory.  Re¬ 
presentative  information  contained  under  the  course  identifi¬ 
cation  include  course  title  and  identification  number,  course 
description,  location,  length  (weeks),  prerequisites,  and 
the  quota  control  command.  The  graduate  status  category 
will  include  data  such  as  number  of  required  graduates  and 
number  of  onboard  graduates.  The  quota  control  category 
should  report  number  of  quotas  available  and  the  class 
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convening  date  (CLCVN) .  The  final  category,  student/ 
graduate  schedule/inventory,  will  include  information  con¬ 
cerning  name,  rate,  division,  course  start/stop  dates,  and 
status  (student  or  graduate) . 

The  school  catalog  summary  program  should  provide  the 
user  with  a  display  or  printout  of  portions  of  the  SRF 
grouped  by  either  course  identification  number  or  course 
short  title.  The  user  will  have  the  option  of  selecting 
various  output  categories  according  to  school,  location,  NEC 
supported,  or  range  of  class  convening  dates.  Information 
provided  by  this  program  includes  course  identification 
number,  title,  location,  length,  and  CLCVN. 

The  required  school  graduate  status  reporting  program  can 
aid  the  user  with  a  terminal  or  hardcopy  list  of  required 
schools  and  the  status  of  the  graduates  of  those  schools. 

Data  provided  in  this  report  includes  course  title,  required 
and  onboard  graduate  count,  and  the  names,  divisions, 
and  PRD'S  of  the  graduates.  Any  future  date  can  be  selected 
to  provide  information  on  required  school  graduate  status. 

The  school  quota  control  program  should  produce  a 
listing  of  quotas,  available  and  filled,  for  the  next  90 
days.  Data  provided  in  this  summary  includes  course 
identificaiton  number,  course  title,  required  graduate 
deficiency  count,  quotas  available,  and  CLCVN. 

The  student  assignment  and  scheduling  program  should 
provide  a  listing  appointed  candidates  and  school  assignment 
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information  concerning  in-progress  and  future  schools. 

Name,  division,  status  (candidate,  student,  graduate), 
course  title,  location,  and  CLCVN  are  representative  data 
items  included  in  this  report. 

Finally,  the  school  orders  preparation  program  should 
produce  the  required  temporary  additional  duty  (TAD)  orders 
for  school  candidates  as  selected  by  the  user. 


IV.  CRITICAL  ANALYSIS 


The  previous  two  chapters  provided  a  description  of  the 
functional  requirements  of  SNAP  and  PTMS.  SNAP  is  intended 
to  automate  a  broad  range  of  shipboard  applications  while 
PTMS  is  aimed  at  a  specific  segment  of  functional  areas; 
personnel  and  training  management. 

The  analysis  of  any  problem  can  be  stated  in  three 
basic  types  of  questions: 

(1)  What  is  the  problem? 

(2)  What  are  the  alternative  solutions? 

(3)  What  is  the  best  solution? 

More  specifically,  the  following  questions  will  be  addressed: 

(1)  What  is  the  problem  that  SNAP/PTMS  are  designed 
to  address? 

(2)  What  are  the  constraints  and  limitations  associated 
with  the  problem? 

(3)  What  are  the  assumptions  associated  with  the  problem? 

(4)  What  is  the  environment;  opportunities,  threats? 

(5)  What  are  the  objectives  of  SNAP/PTMS? 

(6)  What  are  the  alternatives? 

(7)  What  are  the  measures  of  effectiveness  (MOE)  and 
criteria  for  success? 

(8)  Which  is  the  best  alternative  solution  to  the 
problem? 
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The  above  sequence  of  questions  make  up  what  is  known 
as  the  "top  down"  approach  to  analysis.  The  problem  is 
viewed  from  the  perspective  of  the  whole  organization  and 
the  emphasis  is  on  ensuring  that  solutions  satisfy  the 
goal  of  the  organization  as  an  integrated  and  coordinated 
unit. 

A.  PROBLEM  IDENTIFICATION 

The  problem,  as  stated  by  the  Navy,  is  that  there  is 
an  excessive  administrative  burden  on  the  fleets.  The 
questions  might  be  asked;  Is  this  a  valid  problem?  Is  it 
worth  addressing? 

The  problem  of  excess  administrative  burden  on  the  fleets 
is  well  known  but  not  well  documented.  As  stated  in  the 
introduction  to  this  thesis,  "crisis  management"  is  the 
third  ranked  reason  why  mid-grade  officers  are  leaving  the 
service.  Excessive,  unnecessary  paperwork  and  inspections 
were  cited  by  respondents  as  the  main  components  of  crisis 
management.  This  is  qualitative  evidence  at  best. 

It  appears  that,  from  a  qualitative  perspective,  an 
administrative  burden  does  exist  at  the  fleet  level.  But 
is  this  problem  worth  addressing?  From  a  purely  conceptual, 
strategic  viewpoint  the  mission  of  the  Navy  can  be  seg¬ 
mented  into  two  general  functions;  operational  and  support. 
The  Navy's  overall  operational  mission  is  to  provide  national 
defense,  protect  the  sea  lanes  of  communi cation,  and  project 
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a  mobile  force  to  selected  areas  of  the  world.  The  support 
forces  exist  to  aid  the  operational  forces  to  perform  their 
mission.  Obviously,  at  the  organizational  level,  the  more 
resources  that  can  be  directed  to  the  operational  forces, 
the  more  effective  the  national  defense  will  be. 

This  is  the  old  "tooth  and  tail"  delemma.  The  real 
bite  of  national  defense  is  contained  in  the  operational 
forces.  However  the  support  forces  serve  a  vital  role  as 
the  "tail"  of  the  organization.  They  provide  many  logis¬ 
tical  services  that  enable  the  fleet  to  perform  its  job. 

The  problem  in  an  environment  of  scarce  fiscal  and  manpower 
resources  is  to  allocate  those  resources  in  an  efficient 
and  effective  manner.  The  objective  is  to  provide  as  much 
men  and  money  to  the  operational  forces  while  providing  a 
lean  but  effective  support  force. 

The  same  goal  applies  at  the  microscopic  level  of  the 
operational  unit.  The  ship's  limited  availability  of  money, 
manpower,  and  time  must  be  divided  between  operational  and 
support  functions.  The  more  of  these  scarce  resources  that 
can  be  devoted  to  "fighting"  functions,  the  higher  the 
combat  readiness  of  the  unit  will  be.  Therefore  the 
operational  functions  of  personnel  training  and  equipment 
maintenance  should  take  priority  over  the  support  functions 
of  inspections,  reporting,  and  administrative  paperwork. 
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SNAP  and  PTMS  can  reduce  the  cost  of  performing  admin¬ 
istrative  and  support  functions,  in  terms  of  manhours 
consumed. 

This  researcher  is  not  advocating  a  dissolution  of  the 
support  function  but  merely  a  shift  on  the  operational- 
support  spectrum  away  from  support  and  toward  operational 
functions.  Strategies  and  programs  should  be  investigated, 
developed  evaluated,  and  implemented  to  mitigate  the  cost 
of  resources  consumed  by  support  functions  so  that  resources 
can  be  shifted  to  the  operational  functions.  SNAP  and  PTMS 
are  programs  that  serve  this  end. 

B.  CONSTRAINTS  AND  LIMITATIONS 

One  of  the  main  constraints  associated  with  the  problem 
identification  is  that,  although  the  existence  of  the 
administrative  burden  is  known,  the  elements  of  the  burden 
are  not  understood.  Without  a  clear,  quantitative  under¬ 
standing  of  the  elements  of  the  administrative  problem,  a 
scientific  solution  cannot  be  applied.  A  vague  under¬ 
standing  of  the  problem  limits  the  solution  alternatives 
to  imprecise  and  possibly  inappropriate  possibilities. 

Poor  alternatives  neccessarily  produce  less  than  optimal 
solutions . 

To  this  researcher's  knowledge,  a  detailed  analysis  of 
the  functions  of  shipboard  managers  has  not  been  under¬ 
taken.  The  Navy  has  no  quantitative  evidence  on  what 


specific  tasks  a  manager  performs  aboard  ship,  how  long 
each  task  takes,  or  what  percentage  of  the  working  day  a 
shipboard  manager  spends  on  various  types  of  administrative 
tasks . 

A  front-end  solution  to  this  problem  can  be  attained 
through  the  use  of  services  provided  by  the  Navy  Manpower 
and  Material  Analysis  Centers,  Atlantic  and  Pacific.  These 
centers  maintain  teams  of  experts  who  visit  ships,  at  the 
ship's  request,  to  conduct  work  studies.  Work  studies 
involve  developing  improved  work  methods  and  measuring  the 
time  taken  to  accomplish  various  shipboard  tasks.  The 
team  observes  personnel  at  work,  collects  data  on  what 
activities  are  performed,  and  how  long  a  particular  task 
takes.  As  unbiased  observers,  they  can  make  recommendations 
concerning  improved  work  methods . 

It  is  the  recommendation  of  this  researcher  that  the 
Navy  solicit  ships  to  voluntarily  participate  in  a  work 
study  program  for  shipboard  managers.  The  sampling  should 
include  all  officers  plus  selected  enlisted  personnel  who 
perform  personnel  management  functions  (e.g.,  chief  petty 
officers,  leading  petty  officers,  career  counselors,  and 
training  petty  officers)  .  Data  should  be  collected  concerning 
what  administrative  functions  they  perform,  how  long  it 
takes  to  perform  each  type  of  task,  and  what  percentage  of 
the  workday  they  spend  performing  administrative  and  super¬ 
visory  tasks. 
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Armed  with  quantitative  data,  work  study  analysts  can 
begin  to  make  recommendations  of  methods  to  improve  the 
efficiency  and  effectiveness  of  shipboard  managers. 

Certainly  many  tasks  are  candidates  for  consolidation, 
reassignment,  automation,  or  elimination.  By  studying  the 
administrative  functions  of  managers,  the  Navy  can  begin  to 
understand  the  aspects  that  contribute  to  crisis  management 
and  the  administrative  burden  on  the  fleets.  Perhaps  if  a 
work  study  analysis  had  been  conducted  prior  to  the  develop¬ 
ment  of  SNAP,  the  resulting  functional  description  might 
have  looked  quite  different.  It  would  also  have  given  the 
fleet  managers  a  say  in  what  SNAP  should  look  like  from 
their  perspective. 

Another  limitation  in  the  evaluation  of  SNAP/PTMS  is 
that  neither  system  is  available  to  evaluate.  All  that  is 
available  at  this  point  is  the  functional  description  of 
what  the  systems  are  designed  to  do.  Without  the  hard¬ 
ware  and  software  to  analyze,  researchers  are  limited  to  a 
rather  cursory,  qualitative,  and  theoretical  look  at  the 
systems. 

Scarce  resources,  while  not  unique  to  this  problem, 
comprise  another  constraint  to  its  solution.  With  few 
exceptions,  notably  during  wars,  the  Armed  Services  have 
operated  under  fiscal  constraints.  The  services  have 
spent  their  scarce  dollars  on  new  weapons  systems  rather 
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than  people  and  spare  parts.  This  can  be  traced  to  the 
priorities  of  both  Congress  and  the  services. 

Increasingly  complex  weapons  systems  have  created  a 
demand  for  skilled  technicians  to  operate  and  maintain 
them.  Because  of  pay  differentials  that  exist  between  the 
military  and  civilian  sectors,  the  services  have  had  a 
difficult  time  recruiting  and  retaining  technicians.  Mean¬ 
while,  as  the  post-World  War  II  baby  boom  winds  down,  the 
supply  of  18-21  year  old  potential  recruits  is  dwindling. 

In  1978,  the  height  of  the  supply  of  "baby-boomers",  the 
services  had  to  recruit  one  out  of  every  six  eligible 
males  to  maintain  force  strengths.  By  1992,  the  supply 
of  recruits  is  predicted  to  decline  by  25%  and  one  out  of 
four  eligable  males  will  have  to  be  attracted  to  meet 
projected  needs.  [Ref. 7:  p.51]  The  anticipated  shortages 
of  skilled  personnel  along  with  the  historical  budgetary 
pinch  compel  the  Navy  to  seek  means  to  make  its  personnel 
more  efficient  and  effective.  The  Navy  will  have  to  do 
more  with  less  and  these  constraints  limit  the  available 
choices.  Functions  that  are  inordinate  resource  consumers 
will  have  to  be  analyzed  to  determine  if  their  contributions 
to  the  missions  of  the  Navy  are  worth  the  costs  in  terms 
of  money  and  manhours.  Functions  that  are  not  cost-effec¬ 
tive  will  have  to  be  made  more  efficient  or  eliminated. 
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C.  ASSUMPTIONS 


With  SNAP  and  PTMS  in  the  development  stages,  the  ob¬ 
server  cannot  examine  the  systems  "in  the  flesh"  to  see 
how  or  if  they  work  as  advertised.  At  this  point  obser¬ 
vers  can  only  give  the  designers  the  benefit  of  a  doubt 
and  assume  that  SNAP  and  PTMS  will  perform  most  of  the 
designated  functions  as  depicted  in  the  integrated  func¬ 
tional  descriptions. 

D.  ENVIRONMENT 

The  external  environment  consists  of  the  technology 
available  and  the  political  forces  acting  on  the  Navy. 

The  technology  available  is  increasing  at  a  geometric 
rate.  The  capacity  of  computers  has  roughly  doubled 
every  three  years  while  the  cost  per  bit  of  information 
is  steadily  declining.  Today's  computers  are  faster, 
smaller,  more  flexible,  more  reliable,  and  "friendlier" 
to  users  than  yesterday's  computers.  While  the  rate  of 
progress  of  computer  technology  has  not  kept  pace  with 
the  predictions  of  ten  or  fifteen  years  ago,  the  progress 
has  been  steady.  The  continued  advances  in  computer  tech¬ 
nology  is  one  part  of  the  environment  that  users  can  rely 
on. 
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Steady  technological  progress  can  be  contrasted  with 
the  flux  found  in  the  political  environment.  Politicians 
in  the  Executive  and  Legislative  branches  of  the  federal 
government  come  and  go  with  regularity.  They  bring  differ¬ 
ent  policies,  perspectives,  and  priorities  which,  hope¬ 
fully,  reflect  the  changing  moods  of  the  citizens.  Mili¬ 
tary  leaders  have  tried  to  shift  with  the  changing  tides 
with  varying  degrees  of  success.  The  services  engage  in 
constant,  often  bitter,  competition  for  a  larger  piece 
of  the  defense  budget  pie.  Government  agencies  are  re¬ 
quired  to  justify  expenditures  in  cost-effectiveness  terms 
to  ensure  that  the  American  people  are  getting  their  bang 
out  of  the  defense  buck.  The  political  environment  has 
a  definite  effect  on  the  alternatives  available  to  defense 
planners.  As  a  result,  most  defense  projects  operate  on 
a  fixed-effectiveness,  minimum  cost  basis.  Those  projects 
that  do  not  impact  directly  on  the  combat  readiness  of 
the  forces  or  are  perceived  by  legislators  as  too  costly 
have  a  difficult  time  surviving  the  funding  process.  This 
is  perhaps  one  reason  why  the  emphasis  of  SNAP  is  so  heavily 
on  the  maintenance  and  supply  areas . 

There  are  problems  associated  with  the  internal  environ¬ 
ment  as  well.  The  organizational  structure  of  the  Navy 
can  be  described  as  hierarchical  and  institutionalized. 
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Tradition  tends  to  promote  the  status  quo  and  dramatic 
changes  are  often  difficult  to  carry  out  due  to  institu¬ 
tional  inertia.  Compromise,  satisfice,  and  marginal  change 
are  the  watchwords  for  those  who  want  to  survive  in  the 
system  and  thereby  gain  the  seniority/rank  required  to 
make  changes.  The  Navy  way,  standard  operating  procedures 
and  doctrines  may  provide  a  more  cohesive  fighting  force 
but  the  side  effects  tend  to  include  inflexibility  and 
resistence  to  change.  The  administrative  burden  on  the 
fleets  is  a  longstanding  problem  that  requires  new  alter¬ 
natives  to  the  "paperwork  drill".  Convincing  the  bureau¬ 
cracy  that  the  effort  is  worth  the  benefits  may  not  be  easy. 

E.  OBJECTIVES 

The  objective  of  SNAP  and  PTMS  is  to  reduce  the  admin¬ 
istrative  burden  on  the  fleets  through  the  introduction 
of  computers  to  automate  formerly  manual  administrative 
functions.  It  is  anticipated  that  automation  will  pro¬ 
duce  more  accurate  and  timely  preparation  of  required  re¬ 
ports.  It  is  also  hoped  that  automation  will  result  in 
time  savings  and  thus  more  efficient  utilization  of  scarce 
manpower  resources. 

Specifically,  both  SNAP  and  PTMS  are  designed  to 
automate  current  manual  procedures.  Little  attempt  has 


71 


been  made  to  design  new  administrative  procedures.  The 
sheer  volume  of  current  manual  functions  cited  in  the 
last  two  chapters  provide  plenty  of  grist  for  the  computer's 
mill. 

Another  objective  of  SNAP  and  PTMS  is  to  provide  a 
user  friendly  system  that  requires  minimal  training  for 
maintenance  men  and  operators.  It  is  hoped  that  this 
goal  will  minimize  the  cost  of  implementation  and  promote 
the  acceptance  of  the  system  in  the  fleet. 

The  most  important  aspect  of  the  goals  of  SNAP  and 
PTMS  is  that  both  systems  claim  to  be  oriented  toward  the 
operational  fleet  user.  The  purpose  of  SNAP/PTMS  is  to 
reduce  the  administrative  burden  on  the  fleet,  not  the 
shore  establishment.  This  objective  statement  reflects 
an  understanding  that  the  function  of  the  fleet  is  pri¬ 
marily  operational  and  that  reducing  administrative  re¬ 
quirements  at  the  fleet  level  will  ultimately  free  re¬ 
sources  for  commitment  to  operational  objectives.  This 
shift  in  resourse  delegation  should  have  a  direct  positive 
impact  on  fleet  readiness. 

However,  the  history  of  SNAP  described  earlier  shows 
that  from  the  beginning  stages  of  development,  SNAP  con¬ 
centrated  on  the  supply  and  maintenance  applications  al¬ 
most  exclusively.  Out  of  approximately  200  functions  des¬ 
cribed  in  SNAP,  about  175  are  associated  with  supply  and 
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maintenance.  The  shore  establishment  has  a  vested  interest 
in  these  functions  as  they  comprise  the  raison  d'etre  of 
many  of  the  supporting  shore  commands.  The  vast  majority 
of  reports  associated  with  supply  and  maintenance  are 
generated  by  the  fleet  for  the  consumption  of  shore  com¬ 
mands.  The  fleet  user  perceives  these  "outside”  reporting 
requirements  as  just  more  paperwork  which  sits  on  some¬ 
one's  desk  ashore.  From  an  overall  organizational  per¬ 
spective,  these  reports  benefit  the  fleet  through  better 
supply  and  maintenance  support.  But  these  benefits  are 
seen  at  the  fleet  level  as  indirect  and  long  term.  This 
emphasis  on  equipment  tends  to  lose  sight  of  the  Navy's 
most  valuable  resource,  people.  Roughly  65%  of  the  defense 
budget  goes  to  people  programs  and  this  would  appear  to 
be  where  the  Navy  should  focus  its  efforts  to  improve 
administrative  procedures. 

While  SNAP  focuses  on  equipment,  PTMS  is  concerned 
with  people.  PTMS  was  developed  at  the  shipboard  level  by 
functional  users.  The  result  was  a  software  package  that 
satisfied  the  needs  of  personnel  in  the  fleet. 

In  1980,  Commander  Naval  Surface  Forces,  U.  5.  Atlantic 
Fleet  (COMNAVSURFLANT)  authorized  U.S.S.  COONTZ  (DDG-40) 
to  lease  a  mini-computer  system  with  data  management  and 
word  processing  capability.  The  objective  was  to  develop 


and  recommend  ship— initiated  computer  applications  for  in¬ 
clusion  in  the  SNAP  program  [Ref. 83 •  It  is  important  to 
enphasize  that  the  project  was  initiated  by  an  operational 
fleet  commander  and  the  resultant  software  package  was  de¬ 
veloped  at  the  shipboard  level  by  and  for  users.  The 
structure  of  the  Coontz  Data  Management  System  (CDMS) 
is  shown  in  Figure  3.  Perusal  of  Figure  3  shows  that  the 
vast  majority  of  the  applications  generated  at  the  fleet 
level  were  in  the  area  of  administration  and  training. 

This  reflects  where  the  needs  emphasis  exists  at  the  user 
level. 


•  GENERAL  •  ZONE  INSPECTION  •  PQS 

•  JOB/DUTY/WATCH  •  EQUIPMENT  DISCRIPANCY 

•  PLANNING/ TRAINING  •  SUPPLY 

•  SCHOOL 

•  PHYSICAL  SECURITY 

•  MEDICAL 

•  ENLISTED  DINING  FACILITY 


FIGURE  3.  COONTZ  Data  Management  System  Subsystem  Structure 
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It  is  perhaps  unfair  to  criticize  SNAP  for  its  empha¬ 
sis  on  supply  and  maintenance.  Applications  in  these 
areas  might  be  very  difficult  to  develop  at  the  fleet  level. 
Since  PTMS  deals  exclusively  with  personnel  applications 
it  is  more  thorough  than  SNAP  in  this  area.  However  it  is 
the  opinion  of  this  observer  that  the  needs  of  the  ship¬ 
board  user  reflect  a  need  for  greater  emphasis  in  the  area 
of  personnel/ training/administration  than  SNAP  provides. 

F.  ALTERNATIVES 

The  decision  to  automate  shipboard  administrative 
functions  has  already  been  made.  Shipboard  testing  cited 
earlier  revealed  that  installation  of  off-the-shelf  com¬ 
puter  hardware  was  feasible  from  a  reliability  and  mainte¬ 
nance  perspective. 

While  the  software  requirements  for  SNAP  have  already 
been  designed,  one  of  the  main  advantages  of  the  system 
is  that  it  is  designed,  to  be  flexible  enough  to  allow  in¬ 
corporation  of  future  applications.  So  the  question  of 
what  functions  should  be  included  in  the  system  will  con¬ 
tinue  to  be  of  concern  as  SNAP  evolves  over  its  anticipated 
twenty  year  lifetime. 

A  framework  for  analysis  is  helpful  at  this  point. 

The  real  purpose  of  a  computer  is  to  provide  information 
to  support  the  decision-making  process  of  managers.  A 


look  at  the  types  of  decisions,  the  types  of  management 
activity,  and  the  characteristics  of  information  required 
to  make  decisions  is  useful  in  deciding  which  type  of 
computer  software  to  install. 

Anthony  has  provided  a  scheme  for  classifying  decision¬ 
making  in  relation  to  potential  types  of  computer  support. 
[Ref. 9:  pp.81-3]  The  first  level  of  decision-making  is 
called  strategic  planning.  This  is  the  process  of  deciding 
on  objectives  and  the  resources  to  accomplish  the  goals. 
Strategic  planning  normally  involves  top  echelons  of 
management  and  generally  requires  innovation,  creativity, 
and  an  understanding  of  the  organizational  environment. 

The  second  category  is  management  control;  managers 
procure  and  assign  resources  to  assure  the  efficient  and 
effective  accomplishment  of  organizational  objectives. 

This  process  involves  interpersonal  coordination  in  the 
performance  of  tasks. 

The  last  category  of  decision-making  is  called  oper¬ 
ational  control;  the  process  of  assuring  that  tasks  are 
accomplished  in  an  efficient  and  effective  manner.  Pre¬ 
defined,  structured  tasks  are  the  objective  of  operational 
control. 

Obviously  one  cannot  pigeonhole  every  decision  into 
a  discrete  category;  this  scheme  represents  a  continuous 
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spectrum  where  decision  types  overlap  each  other.  The 
information  needs  for  each  type  of  decision  are  very 
different.  Figure  4  shows  the  various  characteristics 
of  information  in  relation  to  the  three  types  of  decisions. 
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FIGURE  4.  Information  Characteristics  By  Area 
of  Decision 
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The  orientation  of  SNAP  and  PTMS  is  toward  the  opera¬ 
tional  control  end  of  the  decision  spectrum.  SNAP  and 
PTMS  are  designed  to  automate  structured  tasks  where  stan¬ 
dard  operating  procedures  are  well  defined  and  efficiency 
of  operation  is  a  main  concern.  At  the  operational  level, 
managers  need  accurate,  detailed  information  for  short 
term  application  to  current  problems. 

The  fact  that  SNAP  is  starting  at  the  lower  end  of  the 
decision  spectrum  has  great  implications  for  the  potential 
growth  of  the  system.  SNAP  has  a  great  deal  of  room  to 
evolve  as  experience  leads  the  way  to  applications  at  the 
managerial  and  strategic  levels.  While  these  types  of 
support  should -be  in  the  back  of  the  designer's  mind, 
concentration  should  be  focused  on  structured  tasks  in 
the  early  stages  of  SNAP  development.  This  is  the  best 
way  to  ensure  a  solid  base  from  which  to  evolve  better 
applications. 

G.  MEASURES  OF  EFFECTIVENESS 

In  order  to  evaluate  SNAP  and  PTMS,  measures  of  effec¬ 
tiveness  (MOE)  are  needed.  Criteria  must  be  established  to 
evaluate  each  application  in  terms  of  the  overall  objective 
of  reducing  administrative  burden. 

SNAP  prototypes  have  already  passed  operational  tests 
for  reliability,  maintainability,  logistics  support,  com- 
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patibility,  interoperability,  and  training  requirements. 
These  criteria,  however,  are  mostly  a  function  of  the 
hardware.  Off-the-shelf  computers  have  proved  their  ability 
to  operate  effectively  in  the  shipboard  environment. 

Users  tend  to  be  more  interested  on  soft  criteria 
such  as  flexibility,  expandibility ,  efficiency,  and  friend¬ 
liness.  Users  want  a  system  that  meets  their  daily  admin¬ 
istrative  needs  and  frees  them  to  perform  operational 
tasks.  Managers  need  a  system  that  can  evolve  to  suit 
changing  needs  and  is  easy  to  operate.  If  users  perceive 
that  SNAP  is  not  meeting  their  needs  or  that  it  is  too 
difficult  to  operate,  they  won't  use  it  and  SNAP  will  be 
a  failure. 

H.  CONCLUSIONS 

Both  SNAP  and  PTMS  are  aimed  at  solving  the  adminis¬ 
trative  burden  at  the  fleet  level.  There  are  some  problems 
associated  with  the  approach  that  the  development  of  SNAP 
has  taken.  Firstly,  little  quantitative  evidence  exists 
concerning  exactly  what  elements  make  up  the  administra¬ 
tive  burden  at  the  fleet  level.  Also  the  development  of 
SNAP  has  taken  the  "top  down"  approach.  SNAP  appears  to 
satisfy  the  data  requirements  of  the  shore  establishments; 
data  which  is  supplied  by  the  fleet.  Hence  there  is  a 
great  emphasis  on  supply  and  maintenance  information 
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applications  in  SNAP.  This  gives  SNAP  the  appearance 
of  existing  by  and  for  the  shore  establishment  as  seen 
by  the  fleet  user. 

The  development  of  PTMS,  however,  has  taken  a  "bottom 
up"  approach.  It  was  developed  by  and  for  fleet  users 
and  more  clearly  reflects  their  needs. 

As  recommended  earlier,  the  Navy  should  undertake  a 
work  study  analysis  at  the  shipboard  level  to  determine 
what  functions  are  performed  by  managers.  This  "bottom 
up"  approach  would  help  define  where  the  administrative 
burden  exists.  Armed  with  quantitative  evidence  concern¬ 
ing  managerial  tasks,  their  periodicity  and  composition, 
analysts  can  assign  functional  priorities  for  inclusions 
in  SNAP .  This  approach  would  ensure  that  the  functions 
included  in  SNAP  were  useful  to  the  shipboard  manager  and 
would  thus  ease  acceptance  to  the  system. 

It  is  also  recommended  that  a  personnel  and  training 
module  similar  to  PTMS  be  incorporated  into  the  nucleus 
SNAP  software  package.  PTMS  reflects  user's  needs  and 
without  the  support  of  personnel  at  the  fleet  level  the 
whole  SNAP  program  may  be  in  jeopardy. 


V.  RECOMMENDATIONS  FOR  INSTALLATION  AND  FUTURE  APPLICATIONS 


A.  INSTALLATION 
1.  Approach 

An  intelligent  approach  to  implementation  is  vital 
to  the  potential  success  of  any  computer  system.  Computer 
specialists  can  design  the  best  system  extant  but  if  the 
hearts  and  minds  of  users  are  not  won  over  during  the  im¬ 
plementation  phase,  the  system  will  probably  fail. 

Computer  analysts  have  used  the  "factor”  approach 
to  study  why  various  computer  implementation  efforts  have 
succeeded  and  others  have  failed.  The  factor  approach 
involves  making  case  studies  of  organizations  to  determine 
what  circumstances  contribute  to  their  success.  Studies 
thus  far  have  revealed  very  few  absolutes  for  success, 
however.  Much  depends  on  the  type  and  size  of  the  organi¬ 
zation,  the  information  requirements,  decision  types, 
management  philosophy,  etc.  However  a  few  general  conclu¬ 
sions  can  be  made.  [Ref. 9:  pp. 195-199] 

Probably  the  most  important  factor  affecting  the 
successful  implementation  is  the  support  of  top  manage¬ 
ment.  Top  managers  set  the  tone  for  the  whole  organiza¬ 
tion  and  their  belief  in  the  computer  system  will  help 
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build  confidence  all  along  the  chain  of  command.  Lower 
level  managers  are  more  likely  to  use  the  system  if  they 
are  encouraged  by  a  top  management  that  actively  supports 
and  uses  the  system. 

A  clear  "felt  need"  is  also  required  by  users. 

This  means  that  the  computer  system  must  address  problems 
which  are  visible  and  relevent  from  the  user's  perspective 
and  are  viable  problems.  Problem  recognition  helps  ensure 
that  the  manager  is  motivated  to  make  a  commitment  to  the 
use  of  the  computer  system. 

Implementors  have  suggested  that  a  lack  of  educa¬ 
tion  is  a  weak  link  in  the  early  stages  of  computer  system 
installation.  Users  at  all  levels  of  the  organization 
must  be  educated  in  the  general  philosophy  behind  the  sys¬ 
tem  as  well  as  the  mechanics  of  system  operation.  Managers 
who  are  not  aware  of  the  problem  addressed  by  the  system 
or  who  do  not  possess  a  "felt  need”  must  be  educated  in 
these  areas.  Hopefully  this  will  help  foster  the  motiva¬ 
tion  and  commitment  required  for  system  success  - 

Part  of  this  education  involves  the  management  of 
change.  Rigidity  and  conformity  are  common  in  large, 
bureaucratic  organizations.  New  technology  can  upset  the 
existing  patterns  of  authority  and  status.  Installation 
specialists  tend  to  ignore  these  human  factors  and  con¬ 
centrate  only  on  the  technical  aspects.  Consultation  of 
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users  is  very  important  to  the  management  of  change. 

There  will  be  a  certain  amount  of  resistance  to  the  intro¬ 
duction  of  SNAP  and  the  early  goals  of  implementation  should 
include  steps  to  mitigate  this  obstacle  to  success.  Manag¬ 
ing  change  can  be  viewed  as  a  three  step  process;  (1)  un¬ 
freezing,  (2)  moving,  and  (3)  refreezing. 

Unfreezing  refers  to  altering  an  individual's 
equilibrium  sufficiently  to  motivate  him  to  accept  change. 
This  can  be  accomplished  by  active  pressure  to  change  or 
by  self-motivation  through  reducing  threats  and  resistance 
to  change . 

Moving  involves  the  actual  changing  of  attitudes 
toward  the  computer  system.  Education  must  win  over  the 
hearts  and  minds  of  users  to  instill  a  belief  that  the 
system  will  help  solve  the  problems  of  the  organization. 

Refreezing  addresses  the  permanent  acceptance 
of  the  system  by  users.  The  system  must  address  the 
needs  of  the  users  if  it  is  to  be  accepted  in  place  of 
the  previous  mode  of  operation. 

Design  and  education  are  the  keys  to  ensure  that 
"factors"  associated  with  successful  implementation  are 
addressed.  If  the  computer  system  is  designed  with  the 
user  in  mind  and  it  addresses  his  needs,  then  much  of  the 
battle  is  won.  If  users  perceive  SNAP  as  "their"  system 
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then  much  of  the  resistance  to  change  will  disappear  be¬ 
cause  motivation  will  provide  the  impetus  ufor  acceptance. 

A  certain  amount  of  education  will  be  required  to  make 
users  aware  of  the  advantages  of  automation.  This  education 
should  start  at  the  ship's  commanding  officer/executive 
officer  level  to  ensure  top  management  support.  Department 
heads  and  division  officers  should  be  given  the  next  priority. 
Prospective  commanding  officer/prospective  executive  officer 
schools.  Department  Head  School,  and  Surface  Warfare  Officer's 
School  are  the  best  sites  to  educate  managers.  SNAP  systems 
should  be  provided  to  these  schools  to  aid  in  the  education  of 
top  management.  Aboard  ships,  education  should  start  well  be¬ 
fore  installation  teams  arrive.  Six  months  prior  to  installa¬ 
tion  the  ship  should  receive  a  package  of  plan-of-the-day 
(POD)  notes  that  describe  the  functional  capabilities  of  SNAP 
in  easy  to  understand  language.  Continuous,  long  term  exposure 
to  the  system  should  help  "unfreeze"  potential  users  and  es¬ 
tablish  self-motivation  for  the  acceptance  of  SNAP.  A  few 
posters  with  pictures  of  the  SNAP  system  and  a  brief  description 
of  its  advantages  should  also  be  provided  for  posting  around  the 
ship. 

2 .  Installation  Teams 

Installation  is  intended  for  about  450  ships  and 
submarines  over  a  five  to  six  year  period  starting  in  mid- 
1982.  This  researcher  proposes  that  the  Navy  utilize 
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installation  vans  similar  to  the  Mobile  Versatile  Training 
System  (MVTS)  located  at  the  Navy  Personnel  Research  and 
Development  Center,  San  Diego.  This  motorized  van  has 
the  capability  to  carry  the  SNAP  central  processing  unit 
(CPU),  a  training  data  base,  high  speed  printer,  and  six 
terminals.  This  configuration  would  provide  a  mobile, 
self-contained  mini-SNAP  system  convenient  for  ship-side 
training. 

An  eight  man  installation/training  team  is  also 
recommended.  This  team  would  include  two  contractor  re¬ 
presentatives  with  technical  skills  (for  installation) 
and  training  skills.  Six  Navy  representatives  should  also 
be  included  in  the  team.  A  LT/LCDR  should  head  the  team 
with  two  technical/ training  enlisted  members  (ET,  IC,  EM, 

DS,  FT,  or  ST)  and  three  training  only  members  (YN,  SK, 
or  other  general  rating) . 

A  one  week  (five  working  day)  installation/ training 
schedule  is  recommended  per  ship.  This  would  permit  two 
vans  (one  per  coast)  to  install  SNAP  on  450  ships  in  just 
over  five  years.  This  schedule  is  based  on  an  eleven  month 
van  availability  to  permit  time  for  van  maintenance,  travel, 
and  team  leave  periods.  Provisions  of  more  than  two  vans 
could  obviously  speed  up  the  delivery  scheduled  considerably 
Days  1-3  should  be  used  to  install  SNAP  aboard  the  ship  and 


condict  user  training  in  the  MVTS.  Days  4-5  should  be 
used  for  onboard  data  base  implementation  assistance.  This 
schedule  is  considered  feasible  since  pre-SNAP  systems  have 
been  installed  in  about  two  and  a  half  days. 

B.  FUTURE  APPLICATIONS 

For  reasons  stated  above,  future  SNAP  programs  should 
take  into  consideration  the  stated  needs  of  fleet  users. 
Periodic  consultation  between  SNAP  designers  and  users 
could  be  accomplished  via  SNAP  conferences  held  at  major 
fleet  ports.  Some  future  applications  are  recommended 
below. 

1.  Routing  Tickler 

One  way  to  cut  down  on  the  volume  of  paper  that 
flows  within  the  ship's  chain  of  command  is  to  put  it  in 
a  computer.  Memorandums  and  message  traffic  are  two  can¬ 
didates  for  inclusion  in  a  SNAP  routing  tickler. 

Many  times  during  the  working  day  a  manager  needs 
to  contact  a  person  on  the  ship  but  is  unable  to  locate 
the  crewmember.  Ship's  service  telephones  have  helped 
in  this  regard  but  legwork  is  all  too  prevalent.  Memos 
are  often  written  but  must  be  delivered  and  tend  to  get 
lost  along  the  way. 

SNAP  should  include  the  capability  to  generate 
memos  to.  any  person  assigned  a  user  identification  number. 
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A  memo  function  could  be  made  available  on  the  SNAP  menu 


for  ease  of  selection.  After  selection  of  the  memo  func¬ 
tion,  the  terminal  should  display  the  billet  names  of  all 
users  as  well  as  convenient  groupings  of  users  (e.g.,  all 
officers,  all  chiefs,  department  heads,  division  officers, 
etc.).  After  selecting  the  routing  list,  the  user  could 
enter  his  memo.  The  memo  should  include  automatic  input 
of  user's  billet  name,  date,  and  time  of  message  genera¬ 
tion.  The  next  time  each  addressee  logs  onto  the  system, 
the  pending  memos  should  automatically  appear  on  the 
terminal. 

2.  Message  Routing/Filing 

Every  ship  receives  volumes  of  message  traffic 
each  day,  especially  during  deployments.  SNAP  should  have 
the  capability  to  route  message  traffic  via  terminals  to 
cut  down  on  the  volume  of  paper  message  traffic. 

The  message  routing  function  should  have  the  capa¬ 
bility  of  permit  memos  to  be  written  on  each  message  to 
facilitate  notification  of  action  officers  by  senior 
managers.  Personnel  receiving  message  traffic  should  have 
the  ability  to  erase,  save  for  future  reference,  or  file 
each  message.  The  filing  capability  should  have  at  least 
two  levels.  For  instance,  a  message  might  pertain  to 
communications  in  a  future  training  exercise.  The  user 
should  be  able  to  file  the  message  under  the  exercise 
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name,  and  within  that  exercise  file,  under  a  communications 
file.  Users  would  be  able  to  set  up  files  to  suit  their 
needs  with  a  file  menu  to  aid  in  retrieval  of  messages. 

3 .  Publications 

Throughout  the  course  of  a  year  each  ship  receives 
various  administrative,  operational,  and  technical  publi¬ 
cations.  Action  officers  rarely  have  time  to  scan,  much 
less  read,  many  of  these  publications. 

All  publications,  manuals,  and  operation  orders 
should  be  received  on  the  ship  in  diskette  form  for  entry 
into  SNAP  memory.  Each  publication  should  contain  an  exe¬ 
cutive  summary  and  a  functional  user  summary.  The  executive 
summary  should  be  brief  and  broad  in  scope  for  quick  perusal 
by  the  commanding  officer  and  personnel  who  do  not  require 
a  detailed  knowledge  of  the  contents.  The  functional  user 
summary  should  be  more  detailed  for  use  by  action  personnel. 
The  executive  summary  should  be  provided  to  authorized  users 
via  the  routing  tickler  with  the  option  to  call  up  the 
functional  user  summary  or  the  document  itself. 

Publication  changes  should  also  be  received  in 
diskette  form  (when  the  ship  in  inport)  to  facilitate  easy 
entry  into  the  original  publication.  It  is  not  unusual  to 
receive  50  separate  changes  to  an  operation  order  and  pen 
and  ink  insertion  is  a  very  time  consuming  process  if  ten 
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or  more  copies  require  updating.  These  changes  should 
also  be  included  in  the  daily  tickler  so  that  action  offi¬ 
cers  are  made  aware  of  them  as  soon  as  possible. 

4.  Computer  Assisted  Instruction  (CAI) 

Computer  assisted  instruction  is  another  area  of 
potential  use  for  SNAP.  Personal  Qualification  Standards 
(PQS)  manuals  and  check-off  books  should  be  inserted  in 
SNAP  to  assist  crewmembers  attain  training  qualifications. 
SNAP  would  be  particularly  beneficial  in  qualification 
testing.  A  master  list  of  questions  from  each  module  could 
provide  a  random  sample  of  test  questions  for  the  student. 
Upon  receiving  a  predetermined  minimum  score,  a  record 
would  be  made  notifying  the  training  petty  officer  that  the 
student  had  qualified  in  that  PQS  item.  Questions  from 
the  Damage  Control  PQS  test  could  be  used  for  ship-wide 
training  via  insertion  in  the  plan-of-the-day . 

5.  Weekly  Planner 

Managers  sometimes  have  difficulty  getting  organized 
for  the  weeks  activities  due  to  the  many  types  of  events 
in  progress.  A  weekly  planner  tailored  to  the  individual's 
schedule  would  help  the  manager  keep  track  of  his  respon¬ 
sibilities.  This  planner  would  provide  automatic  input  of 
scheduling  information  from  the  plan-of-the-day,  planning 
board  for  training,  operation  orders,  memos,  etc. 
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VI.  SUMMARY  AND  CONCLUSIONS 


This  thesis  has  provided  a  description  of  the  func¬ 
tional  requirements  of  the  Shipboard  Non-Tactical  Auto¬ 
mated  Data  Processing  Program  (SNAP)  and  the  Personnel 
Readiness  and  Training  Management  Subsystem  (PTMS) .  SNAP 
is  a  mini-computer  system  proposed  for  installation  in 
ships  and  submarines  starting  in  mid-1982.  Applications 
addressed  by  SNAP  include  maintenance,  supply,  and  person¬ 
nel/administration.  PTMS  is  a  subsystem  that  has  been  pro¬ 
posed  for  inclusion  in  the  SNAP  software.  PTMS  addresses 
the  areas  of  personnel,  administration,  and  training. 

Both  programs  are  being  developed  to  address  the  pro¬ 
blem  of  administrative  burden  at  the  fleet  level.  Analysis 
of  SNAP  from  a  user's  perspective  reveals  that  it  is  heavily 
weighted  toward  the  information  requirements  of  the  shore 
establishment;  namely  the  supply  and  maintenance  functional 
areas.  This  emphasis  may  be  perceived  by  users  in  the  fleet 
as  not  addressing  their  information  needs.  PTMS,  on  the 
other  hand,  was  developed  at  the  fleet  level  and  more  clearly 
addresses  the  administrative  burden  that  exists  there. 

It  is  the  opinion  of  this  author  that  not  enough  quan¬ 
titative  research  has  been  accomplished  on  the  nature  of 
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the  administrative  burden  at  the  fleet  level.  Work  studies 
are  recommended  to  provide  data  on  what  managers  do  aboard 
ships.  This  "on-site"  evaluation  is  necessary  to  the 
development  of  a  computer  system  that  will  meet  the  needs 
of  users  in  the  fleet. 
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